Bug#1055978: mtr-tiny: traceroute does not stop on subnet router anycast addresses

[Rogier Wolff]

                  
> 0.0%     1    1.4   1.4   1.4   1.4   0.0
> 28. 2001:db8:0:2::2                                                          
> 0.0%     1    1.2   1.2   1.2   1.2   0.0
> 29. 2001:db8:0:2::2                                                          
> 0.0%     1    1.4   1.4   1.4   1.4   0.0
> 30. 2001:db8:0:2::2                                                          
> 0.0%     1    1.4   1.4   1.4   1.4   0.0
> 
> 
> On Wednesday, November 15, 2023 11:15 CET, Rogier Wolff 
>  wrote:
>  Hi,
> 
> I'd say this is an unwanted side-effect rather than a bug.
> 
> I'd say the "end-detection" might also consider three times the same
> host responding to be considerd as "the end".
> 
> Originally the TTL, that is now "hop counter" was the "number of
> seconds in the network".
> 
> Thus if there was a queue of 5 seconds before a packet could take
> the next link, the TTL would be decreased by five for that hop. And
> that router should return a TTL EXCEEDED for packets arriving with
> a TTL of 1-5.
> 
> This would, after the suggested change trigger the end-detection. I'm
> thinking that this would be rare enough nowadays to be acceptable.
> 
> The question is: What response are you getting. If it is a "ping
> reply" and not a "time exceeded" we should definitively detct that as
> "target reached". So can you trace the network?
> 
> Can you submit an upstream bugreport on github?
> https://github.com/traviscross/mtr/issues
> 
> Roger.
> 
> 
> On Wed, Nov 15, 2023 at 10:45:28AM +0100, Roland Christanell wrote:
> > Package: mtr-tiny
> > Version: 0.94-1+deb11u1
> > Severity: normal
> > Tags: ipv6
> > X-Debbugs-Cc: li...@christanell.info
> >
> > Dear Maintainer,
> >
> > When I'm trying to use mtr to an 'subnet router anycast address' which 
> > terminates on a linux router, the router answers with the IPv6 address 
> > configured on it's interface and not the anycast address, so the mtr does 
> > not stop.
> >
> > (For the example I use the IPv6 documentation address space)
> > Let's say my linux router has the IPv6 2001:db8:0:1::1/64 and I want to 
> > make a traceroute to 2001:db8:0:1::
> > Example: mtr 2001:db8:0:1::
> > Host Loss% Snt Last Avg Best Wrst StDev
> > 1. :::X:XX 0.0% 3 0.7 1.4 0.7 2.6 1.1
> > 2. :::X:XX 0.0% 3 2.4 1.3 0.7 2.4 1.0
> > 3. :::X:XX 0.0% 3 3.4 4.5 3.4 5.5 1.1
> > 4. 2001:db8:0:1::1 0.0% 3 3.7 3.6 3.5 3.7 0.1
> > 5. 2001:db8:0:1::1 0.0% 3 3.7 3.6 3.5 3.7 0.1
> > 6. 2001:db8:0:1::1 0.0% 3 3.7 3.6 3.5 3.7 0.1
> > 7. 2001:db8:0:1::1 0.0% 3 3.7 3.6 3.5 3.7 0.1
> > 8. 2001:db8:0:1::1 0.0% 3 3.7 3.6 3.5 3.7 0.1
> > 9. 2001:db8:0:1::1 0.0% 3 3.7 3.6 3.5 3.7 0.1
> > 10. ...
> >
> > In my opinion the mtr does not stop, because it does not get an answer from 
> > the requested address, but because it's an 'subnet router anycast address' 
> > the router answers anyway, which is correct.
> >
> > Maybe I'm wrong, but I would expect a result like this:
> > Example: mtr 2001:db8:0:1::
> > Host Loss% Snt Last Avg Best Wrst StDev
> > 1. :::X:XX 0.0% 3 0.7 1.4 0.7 2.6 1.1
> > 2. :::X:XX 0.0% 3 2.4 1.3 0.7 2.4 1.0
> > 3. :::X:XX 0.0% 3 3.4 4.5 3.4 5.5 1.1
> > 4. 2001:db8:0:1:: 0.0% 3 3.7 3.6 3.5 3.7 0.1
> >
> > As far as I found out, it seems to only appear on linux routers, so I'm not 
> > 100% sure if it's a bug in mtr-tiny or a misconfiguration on the linux 
> > routers.
> >
> >
> > -- System Information:
> > Debian Release: 11.8
> > APT prefers oldstable-updates
> > APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
> > 'oldstable')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 5.10.0-26-amd64 (SMP w/1 CPU thread)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=en_US:en
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages mtr-tiny depends on:
> > ii libc6 2.31-13+deb11u7
> > ii libjansson4 2.13.1-1.1
> > ii libncurses6 6.2+20201114-2+deb11u2
> > ii libtinfo6 6.2+20201114-2+deb11u2
> >
> > mtr-tiny recommends no packages.
> >
> > mtr-tiny suggests no packages.
> >
> > -- no debconf information
> >
> 
> --
> ** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
> ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
> f equals m times a. When your f is steady, and your m is going down
> your a is going up. -- Chris Hadfield about flying up the space shuttle


-- 
** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233**
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

Bug#1055978: mtr-tiny: traceroute does not stop on subnet router anycast addresses

[Rogier Wolff]

Hi, 

I'd say this is an unwanted side-effect rather than a bug. 

I'd say the "end-detection" might also consider three times the same
host responding to be considerd as "the end". 

Originally the TTL, that is now "hop counter" was the "number of
seconds in the network".

Thus if there was a queue of 5 seconds before a packet could take
the next link, the TTL would be decreased by five for that hop. And
that router should return a TTL EXCEEDED for packets arriving with
a TTL of 1-5. 

This would, after the suggested change trigger the end-detection. I'm
thinking that this would be rare enough nowadays to be acceptable.

The question is: What response are you getting. If it is a "ping
reply" and not a "time exceeded" we should definitively detct that as
"target reached". So can you trace the network?

Can you submit an upstream bugreport on github?
https://github.com/traviscross/mtr/issues

Roger. 


On Wed, Nov 15, 2023 at 10:45:28AM +0100, Roland Christanell wrote:
> Package: mtr-tiny
> Version: 0.94-1+deb11u1
> Severity: normal
> Tags: ipv6
> X-Debbugs-Cc: li...@christanell.info
> 
> Dear Maintainer,
> 
> When I'm trying to use mtr to an 'subnet router anycast address' which 
> terminates on a linux router, the router answers with the IPv6 address 
> configured on it's interface and not the anycast address, so the mtr does not 
> stop.
> 
> (For the example I use the IPv6 documentation address space)
> Let's say my linux router has the IPv6 2001:db8:0:1::1/64 and I want to make 
> a traceroute to 2001:db8:0:1::
> Example: mtr 2001:db8:0:1::
> Host  Loss%   Snt   Last  
>  Avg  Best  Wrst StDev
> 1. :::X:XX0.0% 30.7   
> 1.4   0.7   2.6   1.1
> 2. :::X:XX0.0% 32.4   
> 1.3   0.7   2.4   1.0
> 3. :::X:XX  0.0% 33.4   
> 4.5   3.4   5.5   1.1
> 4. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 5. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 6. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 7. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 8. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 9. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 10.   ...
> 
> In my opinion the mtr does not stop, because it does not get an answer from 
> the requested address, but because it's an 'subnet router anycast address' 
> the router answers anyway, which is correct.
> 
> Maybe I'm wrong, but I would expect a result like this:
> Example: mtr 2001:db8:0:1::
> Host  Loss%   Snt   Last  
>  Avg  Best  Wrst StDev
> 1. :::X:XX0.0% 30.7   
> 1.4   0.7   2.6   1.1
> 2. :::X:XX0.0% 32.4   
> 1.3   0.7   2.4   1.0
> 3. :::X:XX  0.0% 33.4   
> 4.5   3.4   5.5   1.1
> 4. 2001:db8:0:1:: 0.0% 33.7   
> 3.6   3.5   3.7   0.1
> 
> As far as I found out, it seems to only appear on linux routers, so I'm not 
> 100% sure if it's a bug in mtr-tiny or a misconfiguration on the linux 
> routers.
> 
> 
> -- System Information:
> Debian Release: 11.8
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
> 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-26-amd64 (SMP w/1 CPU thread)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages mtr-tiny depends on:
> ii  libc62.31-13+deb11u7
> ii  libjansson4  2.13.1-1.1
> ii  libncurses6  6.2+20201114-2+deb11u2
> ii  libtinfo66.2+20201114-2+deb11u2
> 
> mtr-tiny recommends no packages.
> 
> mtr-tiny suggests no packages.
> 
> -- no debconf information
> 

-- 
** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233**
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

Bug#967647: mtr: depends on deprecated GTK 2

[Rogier Wolff]

For Debian I then need to create a release I think. 

I'll try to do that soon. Thanks for testing. 

Roger.

On Fri, May 20, 2022 at 12:20:29PM +0200, Jordi Mallach wrote:
> Package: mtr
> Version: 0.95-1
> Followup-For: Bug #967647
> 
> Hi,
> 
> I just tested a build for this and I can confirm this works just
> swapping libgtk2.0-dev with libgtk-3-dev in the Build-Depends.
> 
> Please upload a package linked against libgtk-3-0.
> 
> Thanks,
> Jordi
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ca_ES:ca
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages mtr depends on:
> ii  libc62.33-7
> ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
> ii  libglib2.0-0 2.72.1-1
> ii  libgtk-3-0   3.24.33-2
> ii  libjansson4  2.14-2
> ii  libncurses6  6.3+20220423-2
> ii  libtinfo66.3+20220423-2
> 
> mtr recommends no packages.
> 
> mtr suggests no packages.
> 
> -- no debconf information
> 

-- 
** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233**
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

Bug#999730: mtr: Fix FTBFS with glib2.0 >= 2.70 and deprecated GTimeVal of gtk+2.0

[Rogier Wolff]

Hi, 

I've accepted a patch into upstream that fixes the format errors. 

Roger. 

On Mon, Nov 15, 2021 at 05:21:45PM +0100, Lukas Märdian wrote:
> Package: mtr
> Version: 0.94-2
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source (but built successfully in the past)
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch
> X-Debbugs-Cc: sl...@ubuntu.com
> 
> Hi Robert,
> 
> mtr fails to build from source, if compiled against glib2.0 >= v2.70, due to 
> usage of deprecated GTimeVal in gtk+2.0 headers (that's a dependency of mtr).
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Fix FTBFS with glib >= 2.70 & deprecated definitions of GTimeVal in 
> gtk+2.0
> 
> 
> Thanks for considering the patch.
> 
> Cheers,
>   Lukas
> 
> Build log:
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -pthread 
> -I/usr/include/gtk-2.0 -I/usr/lib/s390x-linux-gnu/gtk-2.0/include 
> -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 
> -I/usr/include/libpng16 -I/usr/include/s390x-linux-gnu 
> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi 
> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/harfbuzz 
> -I/usr/include/glib-2.0 -I/usr/lib/s390x-linux-gnu/glib-2.0/include 
> -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16-g 
> -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> -Wno-pointer-sign -c -o ui/mtr-gtk.o `test -f 'ui/gtk.c' || echo 
> '../'`ui/gtk.c
> ../ui/curses.c: In function ‘mtr_curses_hosts’:
> ../ui/curses.c:435:17: error: format not a string literal and no format 
> arguments [-Werror=format-security]
>   435 | printw(fmt_ipinfo(ctl, addr));
>   | ^~
> ../ui/curses.c:488:21: error: format not a string literal and no format 
> arguments [-Werror=format-security]
>   488 | printw(fmt_ipinfo(ctl, addrs));
>   | ^~
> ../ui/curses.c: In function ‘mtr_curses_graph’:
> ../ui/curses.c:653:17: error: format not a string literal and no format 
> arguments [-Werror=format-security]
>   653 | printw(fmt_ipinfo(ctl, addr));
>   | ^~
> ../ui/curses.c: In function ‘mtr_curses_redraw’:
> ../ui/curses.c:703:5: error: format not a string literal and no format 
> arguments [-Werror=format-security]
>   703 | mvprintw(1, maxx - 25, iso_time());
>   | ^~~~
> ../ui/curses.c:763:42: error: format not a string literal and no format 
> arguments [-Werror=format-security]
>   763 | mvprintw(rowstat - 1, startstat, msg);
>   |  ^~~
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> -Wno-pointer-sign -c -o packet/packet.o ../packet/packet.c
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> -Wno-pointer-sign -c -o packet/cmdparse.o ../packet/cmdparse.c
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> -Wno-pointer-sign -c -o packet/command.o ../packet/command.c
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> -Wno-pointer-sign -c -o packet/probe.o ../packet/probe.c
> In file included from /usr/include/gtk-2.0/gtk/gtkobject.h:37,
>  from /usr/include/gtk-2.0/gtk/gtkwidget.h:36,
>  from /usr/include/gtk-2.0/gtk/gtkcontainer.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkbin.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkwindow.h:36,
>  from /usr/include/gtk-2.0/gtk/gtkdialog.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkaboutdialog.h:32,
>  from /usr/include/gtk-2.0/gtk/gtk.h:33,
>  from ../ui/gtk.c:31:
> /usr/include/gtk-2.0/gtk/gtktypeutils.h:236:1: warning: ‘GTypeDebugFlags’ is 
> deprecated [-Wdeprecated-declarations]
>   236 | voidgtk_type_init   (GTypeDebugFlagsdebug_flags);
>   | ^~~~
> In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
>  from /usr/include/glib-2.0/gobject/gbinding.h:29,
>  from /usr/include/glib-2.0/glib-object.h:22,
>  from /usr/include/glib-2.0/gio/gioenums.h:28,
>  from 

Bug#997194: mtr: FTBFS: ../ui/curses.c:435:17: error: format not a string literal and no format arguments [-Werror=format-security]

[Rogier Wolff]

On Sat, Oct 23, 2021 at 09:07:10PM +0200, Lucas Nussbaum wrote:
> Source: mtr
> Version: 0.94-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs

That's an error in your compiler. 

A printf-like function often has a string litteral specifying the
format

  printf ("a = %d\n", a); 

But it is still just a string. So when I want to print something
either in hex or in dec depending on a user-setting.

I could do something like: 
  printf ("a = ");
  printf (theformat, a);
  printf ("\n");

Now this has become three statements. To compact this a bit more, we 
might do:
  sprintf (format, "a = %s\n", theformat); // format is %d or %x or... set by 
user
  printf (format, a); 

I think this is perfectly legal C code and your compiler doesn't like
it. It doesn't just warn, but gives an error. 

Roger. 

> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -pthread 
> > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
> > -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
> > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
> > -I/usr/include/x86_64-linux-gnu -I/usr/include/pango-1.0 
> > -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/libmount 
> > -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo 
> > -I/usr/include/pixman-1 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid 
> > -I/usr/include/freetype2 -I/usr/include/libpng16-g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wall -Wno-pointer-sign -c -o ui/mtr-curses.o `test 
> > -f 'ui/curses.c' || echo '../'`ui/curses.c
> > ../ui/curses.c: In function ‘mtr_curses_hosts’:
> > ../ui/curses.c:435:17: error: format not a string literal and no format 
> > arguments [-Werror=format-security]
> >   435 | printw(fmt_ipinfo(ctl, addr));
> >   | ^~
> > ../ui/curses.c:488:21: error: format not a string literal and no format 
> > arguments [-Werror=format-security]
> >   488 | printw(fmt_ipinfo(ctl, addrs));
> >   | ^~
> > ../ui/curses.c: In function ‘mtr_curses_graph’:
> > ../ui/curses.c:653:17: error: format not a string literal and no format 
> > arguments [-Werror=format-security]
> >   653 | printw(fmt_ipinfo(ctl, addr));
> >   | ^~
> > ../ui/curses.c: In function ‘mtr_curses_redraw’:
> > ../ui/curses.c:703:5: error: format not a string literal and no format 
> > arguments [-Werror=format-security]
> >   703 | mvprintw(1, maxx - 25, iso_time());
> >   | ^~~~
> > ../ui/curses.c:763:42: error: format not a string literal and no format 
> > arguments [-Werror=format-security]
> >   763 | mvprintw(rowstat - 1, startstat, msg);
> >   |  ^~~
> > gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -pthread 
> > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
> > -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
> > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
> > -I/usr/include/x86_64-linux-gnu -I/usr/include/pango-1.0 
> > -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/libmount 
> > -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo 
> > -I/usr/include/pixman-1 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid 
> > -I/usr/include/freetype2 -I/usr/include/libpng16-g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wall -Wno-pointer-sign -c -o ui/mtr-gtk.o `test -f 
> > 'ui/gtk.c' || echo '../'`ui/gtk.c
> > gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wall -Wno-pointer-sign -c -o packet/packet.o 
> > ../packet/packet.c
> > gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wall -Wno-pointer-sign -c -o packet/cmdparse.o 
> > ../packet/cmdparse.c
> > gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wall -Wno-pointer-sign -c -o packet/command.o 
> > ../packet/command.c
> > gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wall -Wno-pointer-sign -c -o packet/probe.o 
> > ../packet/probe.c
> > In file included from /usr/include/string.h:519,
> >  from ../packet/probe.c:31:
> > In function 

Bug#918778: closed by Guillem Jover (Re: Bug#918778: dpkg does not report all files to be overwritten.)

[Rogier Wolff]

Well, in my case, the ARM compiler in the distribution (Ubuntu)
stopped working (from 16.04 to 18.04). So I had to install a third
party ARM compiler .deb . 

I was going to argue that packaging error can be avoided if there
would be an easy tool that scans an entire repository for duplicate
files, but in this case the ubuntu team would've come up clean.

And again, it can be said that BOTH packages are wrong in installing
that file there. 

But still leaving a potential "dataloss" situation in existance seems
"wrong" to me.

Roger. 




On Tue, Jan 29, 2019 at 10:36:03AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the dpkg package:
> 
> #918778: dpkg does not report all files to be overwritten.
> 
> It has been closed by Guillem Jover .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Guillem Jover 
>  by
> replying to this email.
> 
> 
> -- 
> 918778: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918778
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Tue, 29 Jan 2019 11:31:30 +0100
> From: Guillem Jover 
> To: Roger Wolff , 918778-d...@bugs.debian.org
> Subject: Re: Bug#918778: dpkg does not report all files to be overwritten.
> X-Spam-Status: No, score=-22.5 required=4.0 tests=ALL_TRUSTED,BAYES_00,
>  FROMDEVELOPER,HAS_BUG_NUMBER,TXREP autolearn=ham autolearn_force=no
>  version=3.4.2-bugs.debian.org_2005_01_02
> 
> Hi!
> 
> On Wed, 2019-01-09 at 10:43:08 +0100, Roger Wolff wrote:
> > Package: dpkg
> > Version: 1.19.0.5
> 
> > When installing gcc-avr, I got the error message: 
> > dpkg: error processing archive 
> > /var/cache/apt/archives/gcc-avr_1%3a5.4.0+Atmel3.6.0-1build1_amd64.deb 
> > (--unpack):
> >  trying to overwrite '/usr/lib/libcc1.so.0.0.0', which is also in package 
> > gcc-arm-embedded 7-2018q2-1~bionic1
> > 
> > So because I need the gcc-avr package now, and "not today" the
> > gcc-ARM compiler, I decided to make a backup of the offending file
> > and then force the install of gcc-avr. 
> > 
> > Then I get: 
> > 
> > dpkg: warning: overriding problem because --force enabled:
> > dpkg: warning: trying to overwrite '/usr/lib/libcc1.so', which is also in 
> > package gcc-arm-embedded 7-2018q2-1~bionic1
> > dpkg: warning: overriding problem because --force enabled:
> > dpkg: warning: trying to overwrite '/usr/lib/libcc1.so.0', which is also in 
> > package gcc-arm-embedded 7-2018q2-1~bionic1
> > 
> > so now it has overwritten two files that I did NOT make a backup of!
> 
> Right.
> 
> > I can probably recover by telling dpkg to force-overwrite during
> > a reinstall of the ARM compiler, and it is of course a packaging
> > error of those compilers to use a shared place to store these
> > libraries, but dpkg should have allowed me to make a backup
> > of the files without me having to figure out how to reinstall
> > that ARM compiler while overwriting these shared files. 
> 
> The problem with this request is that the code just errors out on the
> first file conflict, and changing the code to keep going so that it
> can report all other instances would make it messier and error-prone,
> for something that only happens due to packaging errors, when using a
> force option marked as possibly damaging the system, and possibly when
> not having the .debs for the installed packages anymore. :)
> 
> So, I'd rather keep the code as is. What I'd recommend though, which
> might still not help fully in case a package takes over files from
> multiple packages, is to use dpkg-repack to archive the installed
> package contents. But if you can install the other package any time,
> you can always force that in too.
> 
> I'm thus closing this report, sorry!
> 
> Thanks,
> Guillem

> Date: Wed, 9 Jan 2019 10:43:08 +0100
> From: Roger Wolff 
> To: sub...@bugs.debian.org
> Subject: dpkg does not report all files to be overwritten.
> X-Spam-Status: No, score=-10.0 required=4.0 tests=BAYES_00,HAS_PACKAGE,
>  RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no
>  version=3.4.2-bugs.debian.org_2005_01_02
> 
> Package: dpkg
> Version: 1.19.0.5
> 
> 
> When installing gcc-avr, I got the error message: 
> dpkg: error processing archive 
> /var/cache/apt/archives/gcc-avr_1%3a5.4.0+Atmel3.6.0-1build1_amd64.deb 
> (--unpack):
>  trying to overwrite '/usr/lib/libcc1.so.0.0.0', which is also in package 
> gcc-arm-embedded 7-2018q2-1~bionic1
> 
> So because I need the gcc-avr package now, and "not today" the
> gcc-ARM compiler, I decided to make a backup of the offending file
> and then force the install of gcc-avr. 
> 
> Then I get: 
> 
> dpkg: warning: overriding problem because --force enabled:
> dpkg: warning: trying to overwrite '/usr/lib/libcc1.so', which is also in 
> package gcc-arm-embedded 7-2018q2-1~bionic1
> dpkg: warning: 

Bug#839879: mtr FTCBFS: uses build architecture tools

[Rogier Wolff]

On Sat, Sep 30, 2017 at 10:32:04AM +0200, Manuel A. Fernandez Montecelo wrote:
> 2017-09-30 3:39 GMT+02:00 Robert Woodcock :
> > On 09/28/2017 06:41 PM, Manuel A. Fernandez Montecelo wrote:
> >
> > Samuel and I are working on releasing 0.92 - I'll make sure that this is
> > in there. Thanks for the reminder.
> 
> That's great, thanks!

Is there anything I can do upstream to make things easier for you?

Roger.


-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps

[Rogier Wolff]

On Sat, Oct 15, 2016 at 01:00:28AM -0400, Matthew Gabeler-Lee wrote:
> On Thu, 13 Oct 2016, Rogier Wolff wrote:
> 
> >No! Not a "more reasonable" value! An outrageous value!
> >
> >You have a network where 5 hops-in-a-row don't conform to IP standards. And
> >then you expect mtr to work?
> 
> traceroute works fine, ping works fine, tcp connections work fine
> ... but mtr is special and should fail just because the network
> doesn't meet your ideals?  And yeah, MTR would work fine in this
> case if it didn't decide to give up "just because".  The "give up
> after 5" is the /only/ thing preventing it from working properly.
> 
> To put a concrete example to it, consider the case of tunnels, esp.
> VPNs.  It is common for the TTL of the tunneled packet to be copied
> to the outer packet for various good reasons.  But this means that
> traceroute through that tunnel will not return the errors for any
> TTL value that causes the packet to be dropped at points between the
> endpoints of the tunnel, because the error will be returned back to
> the tunnel endpoint, not the original sender.
> 
> Happens with OpenVPN (it's even in their FAQ I think), happens with
> the Cisco IPSEC site-to-site tunnel used at my employer.

To discover the route to a "random" host we could just send out probes
for every distance up to the max TTL. This is wasteful because most of
the targets will be within say 12 hops, so sending out 64 packets is
too much. Another common situation is that you start using mstr to
determine where in the network packets are being dropped. If there is
a 100% blockage at some point, after that moment no further probe will
return results. So to prevent unnecessary load on the network (which
when you're running mtr is already experiencing difficulties) we put
an upper limit on the number of hosts that don't respond. 

Your example with a tunnel is a good one. At first I thought the TTL
should be set to "max" when entering the tunnel, but on second thought
that would be bad: routing / tunneling mishap could then "rejuvenate"
a packet each time it enters the tunnel leading to chaos (packets that
keep running circles and never die). 

Anyway, I've already increased the limit in the development version,
and I thank you for explaining to me why this is becoming more common.

Roger. 


-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps

[Rogier Wolff]

On Wed, Oct 12, 2016 at 03:29:41PM -0400, Matthew Gabeler-Lee wrote:
> Package: mtr
> Version: 0.86-1+b1
> Severity: wishlist
> 
> A new upstream release 0.87 has a fix (of sorts) for the problem where MTR
> will not trace a successful path that has more than five non-responding
> hops.  I say fix "of sorts" because the default limit for this has not been
> changed, but it is now possible to override that default on the command
> line.  FWIW the MTR git shows that an upcoming not-yet-released version also
> increases the default to a more reasonable value.

No! Not a "more reasonable" value! An outrageous value!

You have a network where 5 hops-in-a-row don't conform to IP standards. And
then you expect mtr to work?

Roger. 


> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages mtr depends on:
> ii  libatk1.0-0  2.22.0-1
> ii  libc62.24-3
> ii  libcairo21.14.6-1+b1
> ii  libfontconfig1   2.11.0-6.7
> ii  libfreetype6 2.6.3-3+b1
> ii  libgdk-pixbuf2.0-0   2.36.0-1
> ii  libglib2.0-0 2.50.0-2
> ii  libgtk2.0-0  2.24.31-1
> ii  libncurses5  6.0+20160917-1
> ii  libpango-1.0-0   1.40.3-2
> ii  libpangocairo-1.0-0  1.40.3-2
> ii  libpangoft2-1.0-01.40.3-2
> ii  libtinfo56.0+20160917-1
> 
> mtr recommends no packages.
> 
> mtr suggests no packages.
> 
> -- no debconf information
> 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Bug#839879: mtr FTCBFS: uses build architecture tools

[Rogier Wolff]

Hi Helmut, 

Is there anything I need to do in the upstream sources?  As far as I
can see you patched just the debian build rules, right?

Roger.



On Thu, Oct 06, 2016 at 05:44:13AM +0200, Helmut Grohne wrote:
> Source: mtr
> Version: 0.86-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> mtr fails to cross build from source, because it doesn't pass --host to
> configure. Rather than extending the long line even further, I opted for
> using dh_auto_configure in the attached patch. It also simplifies the
> management of installation paths by leveraging DESTDIR, which is why I
> also had to switch to dh_auto_install. After switching to
> dh_auto_configure cross builds just work. Can you apply it?
> 
> Helmut

> diff --minimal -Nru mtr-0.86/debian/changelog mtr-0.86/debian/changelog
> --- mtr-0.86/debian/changelog 2015-12-07 20:37:45.0 +0100
> +++ mtr-0.86/debian/changelog 2016-10-06 05:27:27.0 +0200
> @@ -1,3 +1,10 @@
> +mtr (0.86-1.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix FTCBFS: Let dh_auto_configure pass cross flags, closes: #-1
> +
> + -- Helmut Grohne   Thu, 06 Oct 2016 05:27:09 +0200
> +
>  mtr (0.86-1) unstable; urgency=low
>  
>* Added patch from Andrew Suffield to use setcap instead of setuid,
> diff --minimal -Nru mtr-0.86/debian/rules mtr-0.86/debian/rules
> --- mtr-0.86/debian/rules 2015-12-07 21:02:22.0 +0100
> +++ mtr-0.86/debian/rules 2016-10-06 05:38:41.0 +0200
> @@ -15,9 +15,9 @@
>  
>   autoreconf -fi
>  
> - mkdir mtr && cd mtr && CFLAGS=-I.. ../configure $(shell dpkg-buildflags 
> --export=configure >/dev/null 2>&1 && dpkg-buildflags --export=configure) 
> $(confflags) --prefix=`pwd`/debian/tmp/usr 
> --mandir=`pwd`/debian/tmp/usr/share/man --sbindir=`pwd`/debian/tmp/usr/bin
> + CFLAGS=-I.. dh_auto_configure --builddirectory=mtr -- $(shell 
> dpkg-buildflags --export=configure >/dev/null 2>&1 && dpkg-buildflags 
> --export=configure) $(confflags)
>  
> - mkdir mtr-tiny && cd mtr-tiny && CFLAGS=-I.. ../configure $(shell 
> dpkg-buildflags --export=configure >/dev/null 2>&1 && dpkg-buildflags 
> --export=configure) $(confflags) --prefix=`pwd`/debian/tmp/usr 
> --mandir=`pwd`/debian/tmp/usr/share/man --sbindir=`pwd`/debian/tmp/usr/bin 
> --without-gtk
> + CFLAGS=-I.. dh_auto_configure --builddirectory=mtr-tiny -- $(shell 
> dpkg-buildflags --export=configure >/dev/null 2>&1 && dpkg-buildflags 
> --export=configure) $(confflags) --without-gtk
>  
>  
>  
> @@ -40,10 +40,8 @@
>  
>  override_dh_installdirs-arch:
>   dh_installdirs -a
> - $(MAKE) -C mtr-tiny prefix=`pwd`/debian/mtr-tiny/usr install
> - mv mtr-tiny/debian/tmp/usr/bin/mtr debian/mtr-tiny/usr/bin/
> - $(MAKE) -C mtr prefix=`pwd`/debian/mtr/usr install
> - mv mtr/debian/tmp/usr/bin/mtr debian/mtr/usr/bin/
> + dh_auto_install --builddirectory=mtr-tiny --destdir=debian/mtr-tiny
> + dh_auto_install --builddirectory=mtr --destdir debian/mtr
>  
>  override_dh_installchangelogs-arch:
>   dh_installchangelogs -a NEWS


-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Bug#824142: mtr 0.86 uses suboptimal colours in curses (patch attached)

[Rogier Wolff]

Hi Adam, 

I'm really busy right now. But if there is a patch out there that I
need to apply "upstream", let me know.

Roger. 

On Thu, May 12, 2016 at 01:40:04PM -0600, Adam Conrad wrote:
> Package: mtr
> Version: 0.86-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu yakkety ubuntu-patch
> 
> 
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Pull commits from upstream to fix terminal colours (LP: #1581186)
> 
> As I note in the LP bug[1], this is hardly a critical issue, but it's
> been driving me nuts since 0.86 landed.  Stupidly, I went and learned
> curses and fixed it locally, which only then gave me the right search
> terms (mtr + use_default_colors) to get Google to point out that it
> was already fixed in upstream git.  So, I threw away my work, grabbed
> the upstream commits, and here we are.
> 
> Would be lovely for you to pick this up in the Debian package, so I
> can delete my recently-added delta from Ubuntu (and so Debian users
> can enjoy slightly less broken colours in mtr in unstable).
> 
> ... Adam
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/mtr/+bug/1581186
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers yakkety
>   APT policy: (500, 'yakkety')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.4.0-21-lowlatency (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

> diff -Nru mtr-0.86/debian/patches/color1.patch 
> mtr-0.86/debian/patches/color1.patch
> --- mtr-0.86/debian/patches/color1.patch  1969-12-31 17:00:00.0 
> -0700
> +++ mtr-0.86/debian/patches/color1.patch  2016-05-12 12:58:21.0 
> -0600
> @@ -0,0 +1,34 @@
> +commit 63a1f1493bfbaf7e55eb7e20b3791fc8b14cf92d
> +Author: Rogier Wolff <r.e.wo...@bitwizard.nl>
> +Date:   Mon Dec 29 09:22:46 2014 +0100
> +
> +added use-default-colors...
> +
> +diff --git a/configure.ac b/configure.ac
> +index d5d1b0e..7199781 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -34,6 +34,9 @@ AC_CHECK_FUNC(initscr, ,
> + AC_DEFINE(NO_CURSES, 1, Define if you don't have the curses libraries 
> available.)
> + CURSES_OBJ=
> + 
> ++AC_CHECK_LIB(ncurses, use_default_colors, 
> ++  AC_DEFINE(HAVE_USE_DEFAULT_COLORS, 1, [Define this if your curses library 
> has the use_default_colors() command.]))
> ++
> + AC_CHECK_FUNCS(attron fcntl)
> + 
> + AC_CHECK_LIB(m, floor, , AC_MSG_ERROR(No math library found))
> +diff --git a/curses.c b/curses.c
> +index 3904cb1..02b7937 100644
> +--- a/curses.c
>  b/curses.c
> +@@ -701,6 +701,9 @@ void mtr_curses_open(void)
> +   raw();
> +   noecho(); 
> +   start_color();
> ++#ifdef HAVE_USE_DEFAULT_COLORS
> ++  use_default_colors();
> ++#endif
> +   int i;
> +   for (i = 0; i < 8; i++)
> +   init_pair(i+1, i, 0);
> diff -Nru mtr-0.86/debian/patches/color2.patch 
> mtr-0.86/debian/patches/color2.patch
> --- mtr-0.86/debian/patches/color2.patch  1969-12-31 17:00:00.0 
> -0700
> +++ mtr-0.86/debian/patches/color2.patch  2016-05-12 12:58:21.0 
> -0600
> @@ -0,0 +1,30 @@
> +commit 7571201cf7a3394e0dcd2b037aba1836089cc084
> +Author: Narthorn <narth...@gmail.com>
> +Date:   Mon Oct 12 13:24:57 2015 +0200
> +
> +curses: Fix background transparency in terminal
> +
> +Patch comes from, and closes traviscross/mtr#72.
> +
> +diff --git a/curses.c b/curses.c
> +index 02b7937..f95f5d1 100644
> +--- a/curses.c
>  b/curses.c
> +@@ -700,13 +700,15 @@ void mtr_curses_open(void)
> +   initscr();
> +   raw();
> +   noecho(); 
> ++  int bg_col = 0;
> +   start_color();
> + #ifdef HAVE_USE_DEFAULT_COLORS
> +-  use_default_colors();
> ++  if (use_default_colors() == OK)
> ++bg_col = -1;
> + #endif
> +   int i;
> +   for (i = 0; i < 8; i++)
> +-  init_pair(i+1, i, 0);
> ++  init_pair(i+1, i, bg_col);
> + 
> +   mtr_curses_init();
> +   mtr_curses_redraw();
> diff -Nru mtr-0.86/debian/patches/series mtr-0.86/debian/patches/series
> --- mtr-0.86/debian/patches/series2015-12-07 12:49:27.0 -0700
> +++ mtr-0.86/debian/patches/series2016-05-12 12:58:41.0 -0600
> @@ -0,0 +1,2 @@
> +color1.patch
> +color2.patch


-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Bug#789083: mtr_0.85.orig.tar.gz contains .o files

[Rogier Wolff]

If I remember correctly I once noticed this, fixed it and promptly had
the somedistribution guys in my neck: They store a hash of the
original distrobuted source in their build-system to make sure that
changing the source without changing the version number is detected
(or a malicious injection of backdoor code!)

It's a mistake. I'll try not to let it happen again, but I can't fix
it retroactively.

Roger. 


On Wed, Jun 17, 2015 at 04:24:14PM +, Rob J. Epping wrote:
 Source: mtr
 Severity: minor
 
 mtr_0.85.orig.tar.gz contains .o files for almost all .c files.
 
 epping@breis:~/src/mtr-0.85$ file *.o
 asn.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 curses.o:  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 display.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 dns.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 getopt1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 getopt.o:  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 gtk.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 mtr.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 net.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 raw.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 report.o:  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 select.o:  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 split.o:   ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 epping@breis:~/src/mtr-0.85$
 
 
 -- System Information:
 Debian Release: 8.1
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable'), (450, 
 'testing-updates'), (450, 'testing')
 Architecture: armel (armv5tel)
 
 Kernel: Linux 3.16.0-4-kirkwood
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 Init: systemd (via /run/systemd/system)
 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731799: Do not work with IPv4 only anymore

[Rogier Wolff]

On Sun, Apr 27, 2014 at 04:29:18PM +0200, Jeroen Massar wrote:
 
 This seems completely unrelated to mtr or let alone Debian...
 
 If your tunnel is broken, then report that to SixXS, there is a nice
 ticket system at https://www.sixxs.net/tickets/. Do provide actual
 details instead of making factless statements in the Debian bug system.
 
 I am one of the users of the chzrh02 PoP and is working like a charm.
 And the rare of chance that it does not, it typically gets reported by
 multiple users and also resolved very quickly. Init7 definitely does care.
 
 If you thus have issues, it definitely is something you have to look into.

I personally have a good understanding of IPV4 and how I've secured my
network against attacks from outside. I know what I'm doing. This
means that I make decisions about what to protect against and what I
won't protect against.

I have decided that I will have fence security: I protect the
outside, I do not put any effort into protecting my machines from an
attacker who is able to access my network. (either by physically
plugging in or by getting control over a machine on my network).

Now this fancy IPV6 comes along. I've been pusing my hosting provider
for an IPV6 address so that I can gain some experience. I'm not
getting it. My provider at work doesn't give me IPV6 access. My
provider at home doesn't. I could tunnel apparently, but although we
hear that IPV4 addresses are running out any moment now time and time
again, nobody around me seems to be hurrying

The little I know about IPV6 is that there won't be a need to
masquerade like we do now. Well, that masquerading is part of my
security strategy. It is for a lot of people. Their machines are not
on a globally routable IP address range, and their border router just
like mine will masquerade for outgoing addresses and automatically
prevent incoming connections, unless explicitly enabled (port
forwarding).

I know that my machines, when running a recent distribution, obtain an
IPV6 address. If my home router suddenly started giving my home
machines routable IPV6 addresses that would break my fence. You'd
suddenly be able to connect to my home machine's http port, which for
example has my paragliding logbook database available to anybody who
can connect. No password no nothing. Just the fence.

I don't have control over the modem. The modem might be upgradeable by
the provider. Or the modem may already be IPV6 enabled, but for now it
doesn't get a routable IPV6 address from the provider. When they change
that, all of a sudden the IPV6 addresses on my network may become
routable.

So... best thing to do is to make sure my machine will never talk
IPV6. How about I compile a kernel without IPV6? Or maybe just boot
with ipv6disable=1?

Roger. 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731799: Do not work with IPv4 only anymore

[Rogier Wolff]

On Mon, Apr 28, 2014 at 09:43:40AM +0200, Jeroen Massar wrote:
 Note that there are a variety of forums that are a much better place
 than a Debian mtr package bug report for these kind of questions.

I'm not asking for help. I'm trying to communicate that I think that
disabling IPV6 is a valid configuration. 

I fully agree with the decisions upstream in debian to enable
IPV6. But you should respect those that may have reasons to disable
it.

 On 2014-04-28 09:08, Rogier Wolff wrote:
  I personally have a good understanding of IPV4 and how I've secured my
  network against attacks from outside. I know what I'm doing. This
  means that I make decisions about what to protect against and what I
  won't protect against.
  
  I have decided that I will have fence security: I protect the
  outside, I do not put any effort into protecting my machines from an
  attacker who is able to access my network. (either by physically
  plugging in or by getting control over a machine on my network).
 
 If your assumption is that, then you are 'safe' with the default
 settings provided by Debian.
 
 Unless somebody sets up a router advertisement to announce a prefix (for
 which they need local access to the network), your host will only have a
 link-local (fe80::/10) address, which means the adversary has local
 access to your network.

I could look this up in under 60 seconds. But I haven't. 

So when my machine asks for an IPV6 address on the link it gets one.
If I'd look it up I'd see it was a link-local address. I'm guessing
similar to the 192.168.x.y that I'm using for IPV4 that they won't
work outside my home network. 

So how do I know that when I boot tomorrow my machine won't get a 
routable IPV6 address? I don't. 

  Now this fancy IPV6 comes along. I've been pusing my hosting provider
  for an IPV6 address so that I can gain some experience.
 
 Chose with your money. If they do not get the picture in 2014, they will
 never get it.

I don't have extra money and time to spare to push issues like
this. If they decide for their clients that without IPV6 I will be
able to manage for now, I'm not going to research or doubt that
decisison. I respect their decision. Life is short. There are a lot of
things in this world that I don't have the time to learn. There are a
lot of things /wrong/ in this world that I don't have the time to
worry about or change. I'm chosing my battles. I'm not into poltics,
I'm into technical things. And even then I choose my battles.

The we need to switch to IPV6 NOW crowd lost credibility with me
when they announced we'll have serious trouble in XXX time when we'll
run out of IPV4 addresses. This was announced three years in a row,
with XXX always less than 12 months. I haven't heard about the IPV4
addresses running out for about a year now. Is the new announcement
going out soon, or did I miss one?

  The little I know about IPV6 is that there won't be a need to
  masquerade like we do now. Well, that masquerading is part of my
  security strategy.
 
 The part that 'masquerading' adds in your 'security strategy' is
 connection tracking. Not the actual act of translating addresses; they
 actually make your box wide open.

The masquerading part helps my security: My machine thinks its address
is 192.168.x.y, and besides people on or very close to my network,
nobody will be able to get packets with that addres to travel to my
machine.

What is they referring to in they actually make...? 

You're saying that masquerading makes my machine wide open?

Are you following the microsoft tactic that OUTgoing connections need
to be firewalled? Sure. On my phone I install apps that should not be
connecting to the internet on a whim. But on my PC I'm more afraid of
the 4 billion internet-users out there, one of which might try to
connect to a service on my machine. At the moment that try to
connect they are now blocked because I don't have a routable internet
address. 

  I know that my machines, when running a recent distribution, obtain an
  IPV6 address. If my home router suddenly started giving my home
  machines routable IPV6 addresses that would break my fence.
 
 If you do not trust machines connection to your local network then you
 should fix that hole in the fence.

My provider will, at some time between 2010 and 2020 decide to enable
IPV6 to their clients. I don't want to have to be there at the moment
they decide to enable it. 

  So... best thing to do is to make sure my machine will never talk
  IPV6. How about I compile a kernel without IPV6? Or maybe just boot
  with ipv6disable=1?
 
 Instead of disabling IPv6, just firewall it:
 
 ip6tables -A INPUT -j REJECT
 ip6tables -A FORWARD -j REJECT

There is more than one way to skin a cat. 

If you think that an outgoing connection that goes through
masquerading is a security risk, will you permit me to consider ipv6
enabled, but firewalled a risk?

To be able to issue the above commands I've had to learn that the
command for ipv6 firewallin

Bug#731799: Do not work with IPv4 only anymore

[Rogier Wolff]

On Mon, Apr 28, 2014 at 12:02:50PM +0200, Jeroen Massar wrote:
  You're saying that masquerading makes my machine wide open?
 
 Bingo. It is no more secure than putting it directly on the network.
 See amongst others http://samy.pl/pwnat/

If I run software on a server inside the NAT it can give away access
to resources behind the NAT.

  #!/bin/sh
  while true ; do
lynx -dump http://www.somedomain.com/lkjasdfkj | sh 
sleep 60
  done

This gives access to my machine to anyone who can register
somedomain.com and install something on the link.

The referenced program and technical paper state that for peer-to-peer
networks this is important. IF peers A and B are on the internet and X
and Y are NATed, then A communicating to B means just set up the
connection. If X wants to communicate with A that's simple as
well. The NAT router will setup the connection once X initiates the
connection. Similarly if B wants to communicate to X, B just has to
trigger (using the protocol somehow) that X starts an outgoing
connection to B. But X communicating with Y becomes problematic. They
have solved this by having the peer-to-peer program silently open up a
connection back into the NATed area.

 Your problem, as you are causing problems for yourself.
 
 That is what this ticket is about: you caused a problem, as the tool
 expects there to be IPv6 support, even if it won't use it.

There is a bug in MTR that it will try to open IPV6 sockets for name
server communication even when explcitly told to do IPV4 only.

I disagree with closing the bug as user-error. 

Roger. 

-- 
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
- Datarecovery Services Nederland B.V. Delft. KVK: 30160549 -
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731799: Do not work with IPv4 only anymore

[Rogier Wolff]

On Mon, Apr 28, 2014 at 02:00:47PM +0200, Jeroen Massar wrote:
 It is only a user-error from the perspective of disabling a current
 protocol. If you disable IPv4 your host won't even boot, even if you
 want it to be IPv6 only.
 
 Using IPv6 support of the networking API (getaddrinfo() and friends) is
 a standard way of porting applications to support both IPv4 and IPv6.

mtr doesn't use getaddrinfo. For a reason. Not a good reason, but
for a reason.

The reason is that it might have many address lookup requests active
at the same time. And it needs to continue to send probe packets and
process the replies. It cannot hang in the getaddrinfo call for five
seconds.

The IMHO correct way to handle this situation would have been to fork
off a process that does the getaddrinfo call, and reports back to the
main process. Alas, that wasn't the way things were implemented back
in theold days, so now we're stuck in mtr with a separate
name-resolving code-block which is buggy and difficult to maintain. 

Roger. 

-- 
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
- Datarecovery Services Nederland B.V. Delft. KVK: 30160549 -
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725222: mtr invoked by command line does nothing

[Rogier Wolff]

On Thu, Oct 03, 2013 at 02:03:08AM -0300, Rogério Brito wrote:
 I'm attaching (as compressed files) the output of running both
 `sudo strace mtr` and `sudo strace mtr --curses`.

That works. 

strace shows: 

// from mtr.c: 
  if ( ( net_preopen_result = net_preopen () ) ) {
fprintf( stderr, mtr: unable to get raw sockets.\n );
exit( EXIT_FAILURE );
  }

ends with: 
  fcntl64(7, F_GETFD) = 0
  fcntl64(7, F_SETFD, FD_CLOEXEC) = 0   


then mtr.c does: 

  /*  Now drop to user permissions  */
  if (setgid(getgid()) || setuid(getuid())) {
fprintf (stderr, mtr: Unable to drop permissions.\n);
exit(1);
  }

  /*  Double check, just in case  */
  if ((geteuid() != getuid()) || (getegid() != getgid())) {
fprintf (stderr, mtr: Unable to drop permissions.\n);
exit(1);
  }

and it shows in the strace:
getgid32()  = 0
setgid32(0) = 0
getuid32()  = 0
setuid32(0) = 0
geteuid32() = 0
getuid32()  = 0
getegid32() = 0
getgid32()  = 0

which works as designed 

And then the code does: 

  /* reset the random seed */
  srand (getpid());

time(NULL)  = 1380776131

which should show up as a call to getpid, and not to time. 
   srand (time (NULL)); 

is a very common call to initialize the random generator, but arguably
the getpid is better for mtr than the time variant.

I haven't touched this code in ages. (I had to think really hard to 
reproduce the choice for getpid as opposed to time). 

The thing is, I'd say that the getpid change is MUCH older than the
IPV6 support that you DO have So what codebase are you running?

OK. Cancel that. The getpid is apparently cached so won't show up in 
strace. 

much later: 

  time_t now = time(NULL);

happens, which is the time call. 

After that mtr should start adding/testing hosts etc. There could have
been a bug in there (which has been fixed in the current version!) 
that would no longer start mtr with the default of localhost if you
don't supply a hostname. So: 

have you tried:

  mtr www.google.com

?

If that works, it's a bug that has been fixed in the main codebase:
either work around it by supplying a hostname, or upgrade if you want.

(I personally think the default of localhost is untidy: cleanlyness
would require mtr to say: no host to trace provided. Bye! (or just
exit wihtout doing anything as it does in your case). However that
means that starting mtr from a menu in a gui without arguments would
make it close immediately.)

Roger. 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725222: mtr invoked by command line does nothing

[Rogier Wolff]

On Thu, Oct 03, 2013 at 06:07:42AM -0300, Rogério Brito wrote:
 It is a common method, indeed. I don't know how/why mtr uses a
 pseudo-random generator, though, without having read the code (will
 read that later, if I still have sufficient interest).

mtr sends out (crafted, non-regular) packets and looks at what comes
back as error messages. At some point in the past, close to the start
of the development of IP (i.e. 1980ies), someone made a mistake that
makes it difficult to determine WHAT packet the returned error
corresponds to. So we have to trick things a bit to make sure that we
associate the response with the correct probe. If we use a
deterministic (e.g. next = cur+1) method, two mtr's running on the
same machine starting out with similar seeds (the first cur) will
continue to recieve eachother's responses. By using a pseudorandom
sequence they might occasionally match a response to the other mtr to
something they sent themselves. But that is very rare. (I think we
have about 15 or 16 bits, so 20 (average # of hops)/3 might be a
good guess).


  If that works, it's a bug that has been fixed in the main codebase:
  either work around it by supplying a hostname, or upgrade if you want.
 
 Yes, passing an argument works fine. Perhaps we need the newest version of
 mtr packaged in Debian...

I haven't released the next version yet. I think Robert is up-to-date
with the latest release. This is first on my platter... 

(next = 0.86, I should have a script that just makes a release, but
that script isn't perfect yet, and needs some hours of debugging which
I can only do when I actually have a release to do AND have the time
to debug the script)

  (I personally think the default of localhost is untidy: cleanlyness
  would require mtr to say: no host to trace provided. Bye! (or just
  exit wihtout doing anything as it does in your case). However that
  means that starting mtr from a menu in a gui without arguments would
  make it close immediately.)
 
 I don't really think that it is *that* unclean of a solution. OTOH,
 just quitting without any message violates the spirit of Unix of
 being noisy when errors occur, while being silent when everything is
 fine.

It isn't an error: You specified nothing to do, so I do nothing.

But agreed, rm without arguments also considers this an error. On the
other hand, in C: 

   for (i=0;in;i++) {
  ...
   }

will run the loop once with n=1, and silently no times at all when you
specify n=0. (which in fact is close to what happened inside mtr
without arguments).

 If mtr issued a message that I missed an argument, then I would not have
 sent this bugreport in the first place. :)

Agreed. But the default is localhost is a very old feature. It was
intended to keep on working. Some feature (multiple hosts) was added
that broke this. noone has wanted to change the old default behaviour.

 Oh, I have a feature request: can you put a button to toggle the name
 resolution in the GUI. :) This way, if name resolution is getting in the
 way, then we can turn it off (or on) very easily.

Yes. that'd be nice. 

Could you paste that into a feature request at 
   https://launchpad.net/mtr/+bugs

Roger. 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#721792: mtr fails without IPv6 socket

[Rogier Wolff]

Hi James, 

Yes. This bug is fix committed in the git repository. But I haven't
released the next version yet.

You can do 
  apt-get build-deps mtr
and then clone the git repository and compile:
  git clone https://github.com/traviscross/mtr.git
  cd mtr
  sh bootstrap.sh ; ./configure ; make
and if all goes well
  sudo make install

That should get you the upgraded version without this bug. 

Roger. 

On Wed, Sep 04, 2013 at 12:17:22AM -0600, James Blanford wrote:
 Package: mtr
 Version: 0.85-1
 Severity: normal
 
 Dear Maintainer,
 
 On a system without IPv6 support, mtr fails on invocation, such as,
 mtr localhost or mtr example.com issuing the error,
 Unable to allocate IPv6 socket for nameserver communication: Address
 family not supported by protocol
 
 I would expect mtr to try IPv4, if IPv6 is not available.
 Partial functioning can be obtained if resolution of hostnames is not 
 requested by adding the -n command line switch.
 
 
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.10.10 (SMP w/2 CPU cores; PREEMPT)
 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages mtr depends on:
 ii  libatk1.0-0  2.8.0-2
 ii  libc62.17-92
 ii  libcairo21.12.14-4
 ii  libfontconfig1   2.10.2-2
 ii  libfreetype6 2.4.9-1.1
 ii  libgdk-pixbuf2.0-0   2.28.2-1
 ii  libglib2.0-0 2.36.4-1
 ii  libgtk2.0-0  2.24.20-1
 ii  libncurses5  5.9+20130608-1
 ii  libpango-1.0-0   1.32.5-5+b1
 ii  libpangocairo-1.0-0  1.32.5-5+b1
 ii  libpangoft2-1.0-01.32.5-5+b1
 ii  libtinfo55.9+20130608-1
 
 mtr recommends no packages.
 
 mtr suggests no packages.
 
 -- no debconf information
 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706816: mtr: new upstream version 0.84 available

[Rogier Wolff]

You mean you want to see a tarball of 0.84 on 
ftp.bitwizard.nl or do you want oseome else to package the
0.84 from
ftp.bitwizard\.nl?

Roge
On Sun, May 05, 2013 at 11:04:56AM +0200, Johann AMSELLEM wrote:
 Package: mtr
 Severity: wishlist
 
 Dear Maintainer,
 
 
 MTR 0.84 is available, please consider packaging it.
 ftp://ftp.bitwizard.nl/mtr/
 
 
 Cheers,

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696060: mtr: StDev overflowed to negative

[Rogier Wolff]

Hi, 

The variance, which is used to calculate the stdev, is stored in a
64-bit integer.

However, what we store there are the squares of the difference from
the average. So if you have 70 second ping time (sometimes), the
square of 7 miliseconds becomes 4900 million! Quite a lot, but
unlikely to overflow a 64-bit value However the calculation is
done in microseconds Thus your 70 seconds is 70 million
microseocnds, giving 4900 trillion (4.9 * 10^15) added to the running
total every second or so, (as long as the average remains around
zero). This can overflow a 64-bit variable in human-observable time.

I've modified the code to do the calculations in miliseconds from now
on. This should buy us a factor of a million of margin. :-)

Roger. 



On Sun, Dec 16, 2012 at 08:30:28AM -0500, The Wanderer wrote:
 Package: mtr
 Version: 0.82-3
 Severity: minor
 
 Dear Maintainer,
 
 As part of an effort to diagnose - and later to confirm the fix of - an
 ongoing network problem, I have maintained an mtr session running for
 several weeks straight.
 
 The current overall summary for one hop in that session presently reads
 as follows:
 
   HostnameLoss  Rcv  Snt  Last   Best  Avg  Worst  StDev
   73.223.7.1  0.3%  4028069  4039341   687 12   60593  -2147483.75
 
 The standard deviation value is negative, which is meaningless AFAIK,
 and therefore should not be possible. The specific negative value in
 question looks at a glance like the result of an overflow.
 
 I am not clear on exactly what it would take to reproduce this problem.
 Presumably, unreasonably high worst-case ping times in what is otherwise
 a normal network environment would be at least a contributing factor.
 However, I am relatively certain that I recall past sessions where this
 hop has shown a Worst value of over 7 milliseconds, but the StDev
 value has remained positive; as such, I am not sure whether that would
 be sufficient.
 
 This bug is of course extremely minor, as even if it does occur
 reproducibly, the circumstances for it are rare and it is unlikely to
 have more than a cosmetic effect even when it does occur. However, as it
 is still a bug, I felt it worth reporting anyway.
 
 If there is anything I can do to help to track this down, please don't
 hesitate to let me know.
 
 
 -- System Information:
 Debian Release: wheezy/sid
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.2.0-3-amd64 (SMP w/12 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages mtr depends on:
 ii  libatk1.0-0 2.4.0-2
 ii  libc6   2.13-35
 ii  libcairo2   1.12.2-2
 ii  libfontconfig1  2.9.0-7
 ii  libfreetype62.4.9-1
 ii  libgdk-pixbuf2.0-0  2.26.1-1
 ii  libglib2.0-02.33.12+really2.32.4-3
 ii  libgtk2.0-0 2.24.10-2
 ii  libncurses5 5.9-10
 ii  libpango1.0-0   1.30.0-1
 ii  libtinfo5   5.9-10
 
 mtr recommends no packages.
 
 mtr suggests no packages.
 
 -- no debconf information
 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#662583: FTBFS

[Rogier Wolff]

On Mon, Mar 05, 2012 at 08:11:52AM +0100, Moritz Muehlenhoff wrote:
 Package: mtr
 Version: 0.82-2
 Severity: serious

(cd mtr;aclocal;automake --foreign --include-deps Makefile;autoconf)

This is the required commandline to satisfy automake. 

Automake is intended to make the buildprocess of packages less
dependent on the specific configuration of individual build-machines.
It fails horribly at it's only task. 

Roger. 



 Your package fails to build from source:
 
 checking for strerror... yes
 checking for getaddrinfo... yes
 checking whether errno is declared... yes
 checking for socklen_t... yes
 checking for struct in_addr... yes
 checking for C flags to get more warnings... -Wall -Wno-pointer-sign
 configure: creating ./config.status
 config.status: creating Makefile
 config.status: creating img/Makefile
 config.status: creating config.h
 config.status: executing depfiles commands
 configure: WARNING: unrecognized options: --enable-gtk2
 make -C mtr
 make[1]: Entering directory `/home/jmm/mtr-0.82/mtr'
  cd ..  /bin/bash /home/jmm/mtr-0.82/missing --run automake-1.11 --foreign
 configure.in:2: version mismatch.  This is Automake 1.11.3,
 configure.in:2: but the definition used by this AM_INIT_AUTOMAKE
 configure.in:2: comes from Automake 1.11.1.  You should recreate
 configure.in:2: aclocal.m4 with aclocal and run automake again.
 WARNING: `automake-1.11' is needed, and you do not seem to have it handy on 
 your
  system.  You might have modified some files without having the
  proper tools for further handling them.  Check the `README' file,
  it often tells you about the needed prerequirements for installing
  this package.  You may also peek at any GNU archive site, in case
  some other package would contain this missing `automake-1.11' 
 program.
 make[1]: *** [../Makefile.in] Error 1
 make[1]: Leaving directory `/home/jmm/mtr-0.82/mtr'
 make: *** [build-stamp] Error 2
 dpkg-buildpackage: error: debian/rules build gave error exit status 2
 
 
 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654117: Please enabled hardened build flags

[Rogier Wolff]

Hi, 

I don't have a debian/rules in my upstream distribution. 

Should I grab a copy somewhere and start distributing it?

Rogier.

On Mon, Jan 02, 2012 at 02:31:30AM +0100, Moritz Muehlenhoff wrote:
 Package: mtr
 Version: 0.82-1
 Severity: important
 Tags: patch
 
 Please enabled hardened build flags through dpkg-buildflags.
 Patch attached.
 
 Cheers,
 Moritz

 diff -aur mtr-0.82.orig/debian/rules mtr-0.82/debian/rules
 --- mtr-0.82.orig/debian/rules2012-01-02 02:26:06.0 +0100
 +++ mtr-0.82/debian/rules 2012-01-02 02:27:45.0 +0100
 @@ -26,10 +26,10 @@
   touch aclocal.m4  \
   touch configure
  
 - mkdir mtr  cd mtr  ../configure $(confflags) 
 --prefix=`pwd`/debian/tmp/usr --mandir=`pwd`/debian/tmp/usr/share/man 
 --sbindir=`pwd`/debian/tmp/usr/bin --enable-gtk2
 + mkdir mtr  cd mtr  ../configure $(shell dpkg-buildflags 
 --export=configure) $(confflags) --prefix=`pwd`/debian/tmp/usr 
 --mandir=`pwd`/debian/tmp/usr/share/man --sbindir=`pwd`/debian/tmp/usr/bin 
 --enable-gtk2
   make -C mtr
  
 - mkdir mtr-tiny  cd mtr-tiny  ../configure 
 --prefix=`pwd`/debian/tmp/usr --mandir=`pwd`/debian/tmp/usr/share/man 
 --sbindir=`pwd`/debian/tmp/usr/bin --without-gtk
 + mkdir mtr-tiny  cd mtr-tiny  ../configure $(shell dpkg-buildflags 
 --export=configure) --prefix=`pwd`/debian/tmp/usr 
 --mandir=`pwd`/debian/tmp/usr/share/man --sbindir=`pwd`/debian/tmp/usr/bin 
 --without-gtk
   make -C mtr-tiny
  
   touch build-stamp
 Nur in mtr-0.82/debian: rules~.


-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#528992: mtr: No DNS resolution in trace, when only IPv6 transport used (no v4 dns hosts in /etc/resolv.conf

[Rogier Wolff]

I expect that this is very difficult to fix: mtr implements its own 
name resolving. It has its own code to contact name servers and such. 

This is bad software engineering. 

I've been thinking about a next generation mtr. 

It will use multiple processes to handle different parts of the 
mtr system. 

So one process will do name resolving. Maybe we'll allow for the old
implementation to perform this function (with the current bug
included!), but certainly we'll have an implementation that simply
calls the getnameinfo function. This will be slower than the current
implementation, as queries to different nameservers will not be issued
in parallel. So another implementation will for off as many processes
as neccesary to do all the name queries in parallel. This will cost
you a peak of say 10 processes all stuck in the getnameinfo function
for a few seconds...

Roger. 


On Sun, May 17, 2009 at 03:59:42AM +0100, Martin List-Petersen wrote:
 Package: mtr
 Version: 0.73-1
 Severity: important
 
 mtr does not resolve the reverse DNS hostnames for any hosts of the trace,
 when only DNS servers with IPv6 addresses are listed in resolv.conf. This
 applies to console (including mtr-tiny) and X11 interfaces. It also applies
 to both IPv4 and IPv6 traces.
 
 If at least one DNS server with IPv4 address is listed, reverse name
 resolution starts working again.
 
 Kind regards,
 Martin List-Petersen
 
 
 -- System Information:
 Debian Release: lenny/sid
   APT prefers stable
   APT policy: (500, 'stable')
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.18-6-686 (SMP w/2 CPU cores)
 Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages mtr depends on:
 ii  libatk1.0-0   1.22.0-1   The ATK accessibility toolkit
 ii  libc6 2.7-13 GNU C Library: Shared libraries
 ii  libcairo2 1.6.4-6.1  The Cairo 2D vector graphics 
 libra
 ii  libglib2.0-0  2.16.6-1   The GLib library of C routines
 ii  libgtk2.0-0   2.12.11-4  The GTK+ graphical user 
 interface 
 ii  libncurses5   5.6+20080830-1 shared libraries for terminal 
 hand
 ii  libpango1.0-0 1.20.5-3   Layout and rendering of 
 internatio
 
 mtr recommends no packages.
 
 -- no debconf information
 
 
 
 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#416567: mostly fixed

[Rogier Wolff]

On Tue, May 12, 2009 at 12:52:21AM -0700, Ryan Niebur wrote:
 retitle 416567 make .deb match override
 quit
 
 this bug is already fixed in the override, which is what really
 matters. however the package needs to be updated to match that.

You mean you're changing copyright notices in the debian override for
a package? If a package's copyright claims are badly worded or simply
incorrect, You CANNOT overide this. I find this somewhere inbetween
bad taste and illegal.

I, however agree with the case at hand, so as the maintainer of the
upstream sources, I can change things. 

Roger. 



-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#416567: mostly fixed

[Rogier Wolff]

On Tue, May 12, 2009 at 08:14:44AM -0700, Ryan Niebur wrote:
 this has nothing to do with copyright at all. the problem is that this

I somehow got a link to a page saying that there was a problem with
some packages claiming to have 

  Copyright
  You may copy according to GPL 

which is incorrect and should be

  Copyright author
  License:
  you may copy according to GPL 

Bug for the bugs-system. 

Enhancement request for the bugs system: 

   Please send the URL of the home page of the bug in every
   changed notification 

 package claims to be in the standard priority of Debian packages,
 while the archive is overriding what it says to set it's priority to
 optional. the difference is that priority standard packages are
 installed by default, while priority optional and lower packages
 must be installed by the user. so the package needs to be changed to
 optional.

Agreed.

Roger. 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#98482: text dump of current data

[Rogier Wolff]

On Thu, Mar 05, 2009 at 08:44:45AM +, George B. wrote:
 Hello,
 
 Any chance this feature can be implemented?
 
 The report function is not sufficient - need to see stats real time
 and yet have the option of grabbing a copy of the data - neither the
 curses interface, nor the GTK one allow selecting and copying of data
 currently on screen.

I don't have the time at the moment. You can try to Email the
mailing list. m...@bitwizard.nl

Roger. 


-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500141: mtr-tiny: Repeatable error

[Rogier Wolff]

On Wed, Dec 17, 2008 at 07:46:12AM -0600, Ron Johnson wrote:
 On 12/17/08 07:35, Rogier Wolff wrote:
 
 what message?
 
 The same message that the creator of this bug complains about.

Well then I have the same answer for you as I had for him. 

Roger. 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500141: mtr-tiny: Repeatable error

[Rogier Wolff]

what message?

This was possibly fixed in the next version. You're having a kenrel
withou IPV6?


Rogier. 

On Wed, Dec 17, 2008 at 07:21:22AM -0600, Ron Johnson wrote:
 Package: mtr-tiny
 Version: 0.75-2
 Followup-For: Bug #500141
 
 
 I  get that same message, too.
 
 -- System Information:
 Debian Release: lenny/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (x86_64)
 
 Kernel: Linux 2.6.27smp64 (SMP w/2 CPU cores)
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages mtr-tiny depends on:
 ii  libc6 2.7-16 GNU C Library: Shared libraries
 ii  libncurses5   5.7+20081129-1 shared libraries for terminal 
 hand
 
 mtr-tiny recommends no packages.
 
 mtr-tiny suggests no packages.
 
 -- no debconf information
 
 
 
 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500141: mtr-tiny: Couldn't get fd's flags: Bad file descriptor

[Rogier Wolff]

On Thu, Sep 25, 2008 at 10:27:14AM -0300, Nelson A. de Oliveira wrote:
 Package: mtr-tiny
 Version: 0.75-2
 Severity: minor
 
 Hi!
 
 Probably inoffensive, but with version 0.75 I get this message when using
 mtr-tiny:
 
   Couldn't get fd's flags: Bad file descriptor

Hi, This is new code, that was supposed to give a small security 
improvement SHOULD other (currently unknown) things go wrong. 

mtr works for you? I think you have IPV6 disabled, and it tries to do
things to the IPV6 socket, which errors out with the above error. 

I've patched my working copy (0.76) to fix this.

Roger. 

 
 Version 0.73 doesn't display it.
 
 Thank you!
 
 Best regards,
 Nelson
 
 -- System Information:
 Debian Release: lenny/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.26.5-naoliv1 (SMP w/2 CPU cores; PREEMPT)
 Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages mtr-tiny depends on:
 ii  libc6 2.7-13 GNU C Library: Shared libraries
 ii  libncurses5   5.6+20080920-1 shared libraries for terminal 
 hand
 
 mtr-tiny recommends no packages.
 
 mtr-tiny suggests no packages.
 
 -- no debconf information
 
 
 
 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#499789: FTBFS: clean target fails: rm: cannot remove `mtr': No such file or directory

[Rogier Wolff]

Hi, 

It works here. 

Maybe you are trying to do make clean within 3 seconds after a make
distclean?

Roger. 


On Mon, Sep 22, 2008 at 01:29:48PM +0200, Christoph Berg wrote:
 Package: mtr
 Version: 0.75-1
 Severity: serious
 Justification: FTBFS
 
 The debian/rules 'clean' target fails:
 
 dpkg-buildpackage: set CFLAGS to default value: -g -O2
 dpkg-buildpackage: set CPPFLAGS to default value:
 dpkg-buildpackage: set LDFLAGS to default value:
 dpkg-buildpackage: set FFLAGS to default value: -g -O2
 dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
 dpkg-buildpackage: source package mtr
 dpkg-buildpackage: source version 0.75-1
 dpkg-buildpackage: source changed by Robert Woodcock [EMAIL PROTECTED]
 dpkg-buildpackage: host architecture amd64
  fakeroot debian/rules clean
 dh_testdir
 dh_testroot
 rm -f build-stamp
 rm -r mtr mtr-tiny
 rm: cannot remove `mtr': No such file or directory
 rm: cannot remove `mtr-tiny': No such file or directory
 make: *** [clean] Error 1
 dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit 
 status 2
 
 Christoph
 -- 
 [EMAIL PROTECTED] | http://www.df7cb.de/



-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#499789: FTBFS: clean target fails: rm: cannot remove `mtr': No such file or directory

[Rogier Wolff]

On Mon, Sep 22, 2008 at 02:16:18PM +0200, Julien Cristau wrote:
 On Mon, Sep 22, 2008 at 14:09:57 +0200, Rogier Wolff wrote:
 
  
  Hi, 
  
  It works here. 
  
  Maybe you are trying to do make clean within 3 seconds after a make
  distclean?
  
 Or maybe you want rm -f.

Mine does include the -f, and looks slightly different from the output
in the report. I can't find the rm without the -f in the
sources. Could it be that automake creates the make clean target from
scratch?

abra2:~/mtr-0.75 make clean
Making clean in img
make[1]: Entering directory `/home/wolff/mtr-0.75/img'
make[1]: Nothing to be done for `clean'.
make[1]: Leaving directory `/home/wolff/mtr-0.75/img'
Making clean in .
make[1]: Entering directory `/home/wolff/mtr-0.75'
test -z mtr || rm -f mtr
rm -f *.o
make[1]: Leaving directory `/home/wolff/mtr-0.75'
abra2:~/mtr-0.75 



-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495840: gqview doesn't display images larger than 32k horizontal pixels correctly

[Rogier Wolff]

Package: gqview
Version: 2.0.1-1
Severity: important


When displaying images with a width greater than 32k pixels gqview
messes up a bit. I'm stitching panoramas and they sometimes have over 
60k horizontal pixels. 

This happens when zoomed out all the way. It doesn't happen when zoomed
in. (I'm suspecting that a signed short is used to count the pixels from
the left of the window or something like that). 



-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686-bigmem
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages gqview depends on:
ii  libatk1.0-0   1.12.4-3   The ATK accessibility toolkit
ii  libc6 2.7-13 GNU C Library: Shared libraries
ii  libglib2.0-0  2.12.4-2   The GLib library of C routines
ii  libgtk2.0-0   2.8.20-7   The GTK+ graphical user interface 
ii  libpango1.0-0 1.14.8-5   Layout and rendering of internatio

Versions of packages gqview recommends:
ii  libjpeg-progs 6b-13  Programs for manipulating JPEG fil

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495840: gqview doesn't display images larger than 32k horizontal pixels correctly

[Rogier Wolff]

On Wed, Aug 20, 2008 at 11:15:13PM +0200, Daniel Baumann wrote:
 severity 495840 normal

Indeed the severity I set sounded a bit hefty, but the description
matched exactly with the situation. 

 tags 495840 +moreinfo
 thanks
 
 Rogier Wolff wrote:
  Package: gqview
  Version: 2.0.1-1
 
 this is a very old version, please retry with lenny.

Tested. Results are the same. 

http://prive.bitwizard.nl/DSC_0081-DSC_0112c_lq.jpg is a 5Mbyte sample
image (220 mpixels). (I set jpg quality to 25, so you'll see a lot
of jpg artefacts. Which is to be expected at .2 bits per pixel)

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#472509: mtr: UDP patch

[Rogier Wolff]

On Tue, Apr 15, 2008 at 04:41:15PM +0200, Martin Pels wrote:
 Depending on whether IP_HDRINCL is defined net_preopen() creates an
 icmp and udp socket, or a single raw socket. 
 
 If we have two sockets it is trivial to close them in
 net_selectsocket(). This is actually what I did in the first version of
 the patch I sent you last year (attached for completeness).
 If we only have a single raw socket there is nothing we need to close.
 
 Closing sockets will inevitably break the GUI u command, because
 after we drop privileges we cannot open new sockets. So maybe we should
 only enable this functionality when raw sockets are available.

OK. Why then was the opening of the sockets delayed to after the
parsing of the cmdline? This is the problem: Lots of complicated code
which might be exploited. I feel much more comfortable passing one (or
two) open sockets down the line towards the rest of the code


Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#472509: mtr: UDP patch

[Rogier Wolff]

On Tue, Apr 15, 2008 at 05:56:36PM +0200, Martin Pels wrote:
 On Tue, 15 Apr 2008 17:15:18 +0200
 Rogier Wolff [EMAIL PROTECTED] wrote:
 
  On Tue, Apr 15, 2008 at 04:41:15PM +0200, Martin Pels wrote:
   Depending on whether IP_HDRINCL is defined net_preopen() creates an
   icmp and udp socket, or a single raw socket. 
   
   If we have two sockets it is trivial to close them in
   net_selectsocket(). This is actually what I did in the first
   version of the patch I sent you last year (attached for
   completeness). If we only have a single raw socket there is nothing
   we need to close.
   
   Closing sockets will inevitably break the GUI u command, because
   after we drop privileges we cannot open new sockets. So maybe we
   should only enable this functionality when raw sockets are
   available.
  
  OK. Why then was the opening of the sockets delayed to after the
  parsing of the cmdline? This is the problem: Lots of complicated code
  which might be exploited. I feel much more comfortable passing one (or
  two) open sockets down the line towards the rest of the code
 
 It is not. We open sockets on line 290, drop privileges on line
 295 and start parsing options and arguments on line 310.

In my version we currently open sockets on line 327, drop permissions
on line 333, and call srand and further things around 345.  Which
version are you looking at. (I'm in my 0.74 directory, which is
currently the same as the released 0.73. )

Roger. 


-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#472509: mtr: UDP patch

[Rogier Wolff]

On Tue, Apr 15, 2008 at 05:56:36PM +0200, Martin Pels wrote:
 On Tue, 15 Apr 2008 17:15:18 +0200
 Rogier Wolff [EMAIL PROTECTED] wrote:
 
  On Tue, Apr 15, 2008 at 04:41:15PM +0200, Martin Pels wrote:
   Depending on whether IP_HDRINCL is defined net_preopen() creates an
   icmp and udp socket, or a single raw socket. 
   
   If we have two sockets it is trivial to close them in
   net_selectsocket(). This is actually what I did in the first
   version of the patch I sent you last year (attached for
   completeness). If we only have a single raw socket there is nothing
   we need to close.
   
   Closing sockets will inevitably break the GUI u command, because
   after we drop privileges we cannot open new sockets. So maybe we
   should only enable this functionality when raw sockets are
   available.
  
  OK. Why then was the opening of the sockets delayed to after the
  parsing of the cmdline? This is the problem: Lots of complicated code
  which might be exploited. I feel much more comfortable passing one (or
  two) open sockets down the line towards the rest of the code
 
 It is not. We open sockets on line 290, drop privileges on line
 295 and start parsing options and arguments on line 310.

In my version, I see the first executable lines in main to be: 

  if ( ( net_preopen_result = net_preopen () ) ) {
fprintf( stderr, mtr: unable to get raw sockets.\n );


and in your patch I see: 


@@ -322,8 +333,21 @@
   struct sockaddr_in6 * sa6;
 #endif
 
-  /*  Get the raw sockets first thing, so we can drop to user euid immediately 
 */
+  /* reset the random seed */
+  srand (getpid());
+  
+  display_detect(argc, argv);
+
+  /* The field options are now in a static array all together, 
+ but that requires a run-time initialization. -- REW */
+  init_fld_options ();
+
+  parse_mtr_options (getenv (MTR_OPTIONS));
+
+  parse_arg (argc, argv);
 
+  /* get raw sockets ASAP, so we can drop to user euid immediately *
+   * we need to do this after parsing options, to know the proto   */
   if ( ( net_preopen_result = net_preopen () ) ) {
 fprintf( stderr, mtr: unable to get raw sockets.\n );
 exit( EXIT_FAILURE );


which I read as: the parse_arg, display_detect and parse_mtr_options
have been moved to BEFORE opening the sockets and dropping privs.

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#472509: mtr: UDP patch

[Rogier Wolff]

Hi guys, 

Looks nice. One problem I have with this is that the amount of code
that is exposed to security problems has gone up a factor of ten... 

How much work would it be to open both the new UDP port and the old
ICMP port, and discard the one we don't need? How can the program
switch (with the GUI u command) if it hasn't preopened the sockets
anyway?

Roger. 



On Mon, Apr 14, 2008 at 11:35:03AM -0400, Mark Kamichoff wrote:
  I wrote a patch for Mtr 0.72 to implement UDP support. You can find it
  attached. UDP mode is enabled using the -u commandline switch, or by
  typing u in the GUI. The patch has been tested on Debian
  testing/unstable, both on IPv4 and IPv6.
 
 I have written a patch (see attached) as well that adds similar UDP
 functionality.  There are some differences in the choice of destination
 ports used, with the original goal of emulating classic traceroute(8)
 behavior.  The port range of 100 can cause erroneous loss on some paths
 since it is used to store sequence numbers, but 'most' of the time it is
 not noticable.
 
 That being said, Martin's patch seems to be the best choice for
 inclusion, as it does not suffer from this problem, and is overall of
 cleaner design.
 
 It would be great to see it included in MTR, as I believe it would add
 considerable flexibility to the utility.
 
 - Mark
 
 -- 
 Mark Kamichoff
 [EMAIL PROTECTED]
 http://prolixium.com/
 Rensselaer Polytechnic Institute, Class of 2004

 Only in mtr-0.72-new: .deps
 diff -ur mtr-0.72/ChangeLog mtr-0.72-new/ChangeLog
 --- mtr-0.72/ChangeLog2004-08-26 03:56:53.0 -0400
 +++ mtr-0.72-new/ChangeLog2008-04-14 10:33:16.0 -0400
 @@ -1,3 +1,24 @@
 +2008-04-13  Mark Kamichoff  [EMAIL PROTECTED]
 +
 + * Changed the UDP sequence number storage to be source port -
 + UDP_PORT_MIN.  This allows us 100 packets to be in-flight at any
 + time, without losing track.  Right now we're using the classic
 + traceroute ports, but might need to increase this in the future.
 + * Added UDP checksum calculation for both IPv4 and IPv6.  Source
 + address _must_ be specified at this point, due to a problem with
 + getsockname(2) not filling in the address structure completely.
 + * Added a line in the curses output to display protocol type.
 + * Fixed IPv6 support (see first entry).
 +
 +2008-04-11  Mark Kamichoff  [EMAIL PROTECTED]
 +
 + * Fixed bug displaying localaddr (always displayed ANY)
 +
 +2007-03-27  Mark Kamichoff  [EMAIL PROTECTED]
 +
 + * Preliminary UDP (-P udp) support.  IPv6 doesn't work with it,
 + yet, since we're using the IP ID field for sequence numbers.
 +
  2002-03-06  Cougar [EMAIL PROTECTED]
   + If hop doesn't respond, draw its name in red (GTK) or bold (curses)
  
 Only in mtr-0.72-new: Makefile
 Only in mtr-0.72-new: config.h
 Only in mtr-0.72-new: config.log
 Only in mtr-0.72-new: config.status
 diff -ur mtr-0.72/curses.c mtr-0.72-new/curses.c
 --- mtr-0.72/curses.c 2006-09-29 15:40:09.0 -0400
 +++ mtr-0.72-new/curses.c 2008-04-14 10:33:16.0 -0400
 @@ -75,6 +75,7 @@
  extern int tos;
  extern float WaitTime;
  extern int af;
 +extern int protocol;
  
  void pwcenter(char *str) 
  {
 @@ -506,6 +507,22 @@
time(t);
mvprintw(1, maxx-25, ctime(t));
  
 +  /* display protocol -- MK */
 +  if(protocol == 17) {
 +mvprintw(2, 0, Protocol: UDP\n);
 +  } else {
 +#ifdef ENABLE_IPV6
 +switch ( af ) {
 +case AF_INET6:
 +  mvprintw(2, 0, Protocol: ICMPv6\n);
 +  break;
 +#endif
 +case AF_INET:
 +  mvprintw(2, 0, Protocol: ICMP\n);
 +  break;
 +}
 +  }
 +
printw(Keys:  );
attron(A_BOLD); printw(H); attroff(A_BOLD); printw(elp   );
attron(A_BOLD); printw(D); attroff(A_BOLD); printw(isplay mode   );
 Only in mtr-0.72-new: curses.o
 Only in mtr-0.72-new: display.o
 Only in mtr-0.72-new: dns.o
 Only in mtr-0.72-new: getopt.o
 Only in mtr-0.72-new: getopt1.o
 Only in mtr-0.72-new/img: Makefile
 Only in mtr-0.72-new: mtr
 diff -ur mtr-0.72/mtr.c mtr-0.72-new/mtr.c
 --- mtr-0.72/mtr.c2006-09-29 15:38:49.0 -0400
 +++ mtr-0.72-new/mtr.c2008-04-14 10:33:16.0 -0400
 @@ -65,6 +65,7 @@
  int   bitpattern = 0;
  int   tos = 0;
  int af = DEFAULT_AF;
 +int   protocol = 1; /* protocol number: icmp or udp */
  
  /* begin ttl windows addByMin */
  int  fstTTL = 1;/* default start at first hop */
 @@ -145,6 +146,7 @@
  { max-ttl, 1, 0, 'm' },
  { inet, 0, 0, '4' },   /* IPv4 only */
  { inet6, 0, 0, '6' },  /* IPv6 only */
 +{ protocol, 1, 0, 'P' },
  { 0, 0, 0, 0 }
};
  
 @@ -152,7 +154,7 @@
while(1) {
  /* added f:m:o: byMin */
  opt = getopt_long(argc, argv,
 -   vhrxtglpo:i:c:s:b:Q:na:f:m:46, long_options, NULL);
 +   vhrxtglpo:i:c:s:b:Q:na:f:m:46P:, long_options, NULL);
  if(opt == -1)
break;
  
 @@ -264,6 

Bug#472511: mtr: Sub-second interval patch

[Rogier Wolff]

Applied. 

Will go out in the next version when it comes out. 


Rogier

On Mon, Mar 24, 2008 at 07:03:04PM +0100, Martin Pels wrote:
 Subject: mtr: Sub-second interval patch
 Package: mtr
 Version: 0.72
 Severity: wishlist
 Tags: patch
 
 Hi,
 
 In the current version of mtr, intervals smaller than 1 second are only
 supported when specified on the command line. The attached patch
 modifies mtr to allow for specifying an interval between 0 and 1
 seconds via the GUI.
 
 -- System Information:
 Debian Release: lenny/sid
   APT prefers unstable
   APT policy: (600, 'unstable'), (500, 'oldstable'), (500, 'stable')
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.18-4-486
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages mtr depends on:
 ii  libc6 2.7-9  GNU C Library: Shared
 libraries ii  libglib1.21.2.10-17  The GLib library
 of C routines ii  libgtk1.2 1.2.10-18  The GIMP
 Toolkit set of widgets fo ii  libncurses5   5.6+20080308-1
 Shared libraries for terminal hand pn  xlibs
 none (no description available)
 
 mtr recommends no packages.

 diff -Naur mtr-0.72.orig/curses.c mtr-0.72/curses.c
 --- mtr-0.72.orig/curses.c2006-09-29 21:40:09.0 +0200
 +++ mtr-0.72/curses.c 2008-03-24 16:11:40.0 +0100
 @@ -19,6 +19,7 @@
  
  #include config.h
  #include strings.h
 +#include unistd.h
  
  #ifndef NO_CURSES
  #include ctype.h
 @@ -93,6 +94,7 @@
  {
int c = getch();
int i=0;
 +  float f = 0.0;
char buf[MAXFLD+1];
  
if(c == 'q')
 @@ -169,10 +171,13 @@
buf[i++] = c;   /* need more checking on 'c' */
  }
  buf[i] = '\0';
 -i = atoi( buf );
  
 -if ( i  1 ) return ActionNone;
 -WaitTime = (float) i;
 +f = atof( buf );
 +
 +if (f = 0.0) return ActionNone;
 +if (getuid() != 0  f  1.0)
 +  return ActionNone;
 +WaitTime = f;
  
  return ActionNone;
}


-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#461049: coreutils: dd no longer reports xx+yy records in|out after sigpipe.

[Rogier Wolff]

On Mon, Jan 28, 2008 at 10:50:23PM -0700, Bob Proulx wrote:
 Michael Stone wrote:
  Rogier Wolff wrote:
 dd if=somebigfile | dd count=100 of=/dev/null 
  
  both dd's should report that they copied 100 records. This worked in
  debian sarge. Debian Etch, the first dd stopped reporting the number
  of records copied. The script I wrote then stopped working. 
  (The above is an example, my script of course used something else
  than dd count=100 to limit the size copied.)
  
  I haven't replied yet because I'm not sure what to make of it. It 
  definitely does behave this way. Anyone else know if this was an 
  intentional change or a bug? I don't see anything obvious in the 
  changelog, and my reading of posix suggests that it's a bug; am I 
  missing something?
 
 I can't reproduce this behavior.  This is what I see:
 
   $ dd if=/dev/zero | dd count=100 of=/dev/null
   100+0 records in
   100+0 records out
   51200 bytes (51 kB) copied, 0.00245 seconds, 20.9 MB/s
 
   $ dd --version
   dd (coreutils) 5.97
 
   $ $ uname -rm
   2.6.18-5-amd64 x86_64
 
   $ uname -rm
   2.6.22-3-686 i686


Yes, you /can/ reproduce the bad behaviour. Your output shows the 
bad behaviour. :-)


Good behaviour: 

driepoot:~  dd if=/dev/zero | dd count=100 of=/dev/null
100+0 records in
100+0 records out
51200 bytes transferred in 0.000553 seconds (92582676 bytes/sec)
129+0 records in
128+0 records out
65536 bytes transferred in 0.002203 seconds (29747044 bytes/sec)
driepoot:~ dd --version
dd (coreutils) 5.2.1
[...]
driepoot:~ 


There are two dd processes. The second one will copy over exactly
100 blocks, and then exit. It should report 100 blocks in, 100 
blocks out. This works. 

The other dd has an unlimited amount of input data (/dev/zero), and
it's output pipe is closed after 100 blocks of dat is consumed. The
pipe can hold a little more data, so actually it will have read
and subsequently written more than 100 blocks (in my case 128). 

So, when 100 blocks were written and consumed by the other side of 
the pipe, 28 more blocks were in the pipe, when the system noticed
that the other side of the pipe was closed, and returned EPIPE
to the first dd. 

Let me reiterate: It is the first dd that is misbehaving, when it
recieves a write error and SIGPIPE, it simply exits instead of
reporting the stats. 

using strace on the first dd shows (good behaviour on an older
system!):

[...]
read(0, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 512) = 512
write(1, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 512) = -1 
EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
close(0)= 0
close(1)= 0
write(2, 101+0 records in\n, 17101+0 records in
)  = 17
write(2, 100+0 records out\n, 18100+0 records out
) = 18
gettimeofday({1201594453, 321231}, NULL) = 0
write(2, 51200 bytes transferred in 0.025..., 6451200 bytes transferred in 
0.025491 seconds (2008543 bytes/sec)
) = 64
gettid()= 13885
tgkill(13885, 13885, SIGPIPE)   = 0
sigreturn() = ? (mask now [])
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++
driepoot:~ 

or (bad behaviour at an upgraded system): 

[...]
read(0, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 512) = 512
write(1, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 512) = -1 
EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++
Process 11355 detached


Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#461049: coreutils: dd no longer reports xx+yy records in|out after sigpipe.

[Rogier Wolff]

On Tue, Jan 29, 2008 at 03:12:24PM +0100, Jim Meyering wrote:
 Rogier Wolff [EMAIL PROTECTED] wrote:
  On Tue, Jan 29, 2008 at 08:01:45AM -0500, Michael Stone wrote:
  I figured there'd be some piece of posix at the bottom of it. :) I
  wonder if the documentation should better reflect that. (The info page
  says only that when dd completes it outputs the final statistics; maybe
  something like when dd completes normally or is killed by SIGINT it
  outputs the final statistics?)
 
  When I use dd to fill a floppy, (I could use cp, but dd outputs the
  size of the data copied, which helps me verify things went as planned),
  I want to see 1440 blocks copied.
 
 You were reporting that this didn't work the way
 you expected:
 
$ dd if=/dev/zero | dd count=100 of=/dev/null
 
 The real solution is just don't do that (i.e., don't use the
 unnecessary pipe).   Do this instead:
 
 $ dd if=/dev/zero count=100 of=/dev/null

As reported in the original bugreport: 

Of course, the two dd's are unneccesary, and this could be done with
one dd. In practise, the consumer (second dd) is another program that
exits when it's had enough data. The output of (the first) dd is then
used to extract the approximate amount of data copied. 

The script that, after an system-upgrade, stopped working of course
uses a different program, which I'm not sure you have. So I decided to
provide an example, for which I didn't have to provide any data files
and other unusual programs.

This is a simple test case, which regrettably uses a second dd to
limit the amount of data that can be copied. . This results in two different
possibilities if miscommunication: First someone reports seeing 100+0
records copied from the second dd, which is of course correct, but
the bug lies in the first dd no longer reporting the amount of data
copied.

The second case, is your interpretation that one dd would be
unneccesary as it could be done with just one. 

Roger. 


-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#461049: dd's reaction to a close of the output. (Bug#461049)

[Rogier Wolff]

Hi,

In the past, the dd program would report the number of records
copied when it stopped. dd stopping can of course be caused by
several things: Running out of input, input IO error, output
io error, or the case of interest here, the output pipe getting 
closed. 

Someone has quoted the standard to say: 

ASYNCHRONOUS EVENTS

For SIGINT, the dd utility shall interrupt its current processing,
write status information to standard error, and exit as though
terminated by SIGINT. It shall take the standard action for all
other signals; see the ASYNCHRONOUS EVENTS section in Section 1.4
(on page 2280).

and as dd recieves a SIGPIPE when an output pipe is closed, 
this was interpreted as: in that case dd is NOT ALLOWED to print
any statistics output. 

In my case, I used the dd program as an intermediary in a pipe, and the 
statistics output was used to get a rough (how much data
was already in the pipe buffer is unknown) estimate of the amount
of data copied. The new claimed-to-be-compliant dd no longer outputs
the amount of data copied, resulting in failure of the script. 

This is of course the opposite of the intent of a standard 


My questions are these: 

Is the standard indeed intended to silence dd in case of the output
being a pipe, and the reading end of the pipe being closed?

If so, what arguments are used to support such a decision? It is imho
very odd that dd would report the amount of data copied for almost all
situations except when the output happens to be a pipe, and the
reason for stopping happens to be the output being closed. 

Is there any historical dd that would behave like this, where the
standard would describe it's behaviour, to standardise this behaviour
for compatiblity reasons?

Best regards, 

Roger Wolff. 

P.S. It's the FSF coreutils maintainers that apparently interpret
the standard this way, and modified their version of dd to no longer 
report the statistics in this case. (claiming standards-compliance
as the reason for the change) This caused a script I wrote 
to fail.  I am not interested in getting my script to run again. 
It already does: I wrote a simple subset of dd to simply report
the number of blocks copied, even in the case of the output
pipe being closed. I'm interested in this subject to make the
standard work as intended: to increase interoperability. My, 
and other people's scripts should keep on working across platforms
and versions, instead of requiring manual fixups after each update. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#461049: coreutils: dd no longer reports xx+yy records in|out after sigpipe.

[Rogier Wolff]

 +and when @command{dd} completes normally or is killed by the
 [EMAIL PROTECTED] signal, it outputs the final statistics.

Which is not correct, as the stats are also printed upon write error,
like ENOSPC. (as we all agree the standards require). 

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#461049: coreutils: dd no longer reports xx+yy records in|out after sigpipe.

[Rogier Wolff]

On Tue, Jan 29, 2008 at 08:01:45AM -0500, Michael Stone wrote:

 I figured there'd be some piece of posix at the bottom of it. :) I 
 wonder if the documentation should better reflect that. (The info page 
 says only that when dd completes it outputs the final statistics; maybe 
 something like when dd completes normally or is killed by SIGINT it 
 outputs the final statistics?)

When I use dd to fill a floppy, (I could use cp, but dd outputs the
size of the data copied, which helps me verify things went as planned), 
I want to see 1440 blocks copied. 

So when I have an image of which the first 1440kbytes should be copied
to a floppy, I want

dd if=my.img of=/dev/fd0 bs=1k

to report 
1440+0 records out

This is my verification that all data got copied as intended. If 
my image is larger than 1440 kbytes, I expect to see
1441+0 records in
and dd will experience a ENOSPC on the 1441'th write. 

AGAIN: dd is used to copy data, and to provide feedback on howmuch
data it copied. It is inconsistent to omit the feedback in some cases
when the copying stops. Copying can stop because of several reasons:
Two I can think of are: no more input, and output no longer
possible. ENOSPC on a device, or a file (disk full), is quite
similar, and should be handled similar to EPIPE on the output.

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#461049: coreutils: dd no longer reports xx+yy records in|out after sigpipe.

[Rogier Wolff]

On Tue, Jan 29, 2008 at 01:27:57PM +0100, Jim Meyering wrote:
 Rogier Wolff [EMAIL PROTECTED] wrote:
 ...
  Let me reiterate: It is the first dd that is misbehaving, when it
  recieves a write error and SIGPIPE, it simply exits instead of
  reporting the stats.
 
 Thanks for the report, but that behavior is required by POSIX.
 dd must handle SIGINT the way you want, but dd may not handle
 SIGPIPE that way:
 
 ASYNCHRONOUS EVENTS
 
 For SIGINT, the dd utility shall interrupt its current processing,
 write status information to standard error, and exit as though
 terminated by SIGINT. It shall take the standard action for all
 other signals; see the ASYNCHRONOUS EVENTS section in Section 1.4
 (on page 2280).

Please interpret it as dd is supposed to work: 

Please block the SIGPIPE signal, then write will return: 

   EPIPE  fd is connected to a pipe or socket whose reading end is
  closed.  When this happens the writing process will also
  receive a SIGPIPE signal.  (Thus, the write return
  value is seen only if the program catches, blocks or
  ignores this signal.)

then the write will return EPIPE, which is a normal error code,
indicating that writing has stopped, and that stats should be printed.

What is dd's purpose in life? Device-to-device copy, as it's name
suggests? Turns out modern use is often no longer device-to-device. It
copies files, and counts and reports the number of blocks copied. This
feature is used by some. If you go and change it, things will stop
working.

If you start waving standards around, I'll bounce it back for
you. SIGPIPE is NOT an asynchronous event. As documented in the quoted
documentation for write. It happens synchronously with the write,
normally before the return of EPIPE. 

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#461049: coreutils: dd no longer reports xx+yy records in|out after sigpipe.

[Rogier Wolff]

On Tue, Jan 29, 2008 at 03:33:01PM +0100, Jim Meyering wrote:
 Rogier Wolff [EMAIL PROTECTED] wrote:
  On Tue, Jan 29, 2008 at 01:27:57PM +0100, Jim Meyering wrote:
  Rogier Wolff [EMAIL PROTECTED] wrote:
  ...
   Let me reiterate: It is the first dd that is misbehaving, when it
   recieves a write error and SIGPIPE, it simply exits instead of
   reporting the stats.
 
  Thanks for the report, but that behavior is required by POSIX.
  dd must handle SIGINT the way you want, but dd may not handle
  SIGPIPE that way:
 
  ASYNCHRONOUS EVENTS
 
  For SIGINT, the dd utility shall interrupt its current processing,
  write status information to standard error, and exit as though
  terminated by SIGINT. It shall take the standard action for all
  other signals; see the ASYNCHRONOUS EVENTS section in Section 1.4
  (on page 2280).
 
  Please interpret it as dd is supposed to work:
 
  Please block the SIGPIPE signal, then write will return:
 ...
  If you start waving standards around, I'll bounce it back for you.
 
 You're beating a dead horse already.
 You'll need to come up with much better arguments (that probably
 do not exist) to make me change dd to be non-compliant in this respect.

In my interpretation of the quoted part of the standard, dd has become
non-compliant, by not reporting the statistics when its output happens
to be connected to a pipe.

I will agree that my interpretation is a bit convoluted. But it's a
valid interpretation, and it makes dd do the sensible thing.

It currently implements a weird exception, fuelled by a litteral,
interpretation of unintentional wording in a standard.

I'm all in favor of standards. However, blindly implementing an
unintentional consequence of a standard is not the way to improve
interoperability.

The INTENT of the that part of the standard was to say that dd
implementations need not catch-and-handle all possible signals.

If any other dd can be found that behaves like gnu-dd does now, which
warrants gnu-dd to comply to an unintentional consequence of some
interpretation of the standard, I'll concede.

If any other user can be found who is surprised by dd outputting the
stats after the output pipe is closed (but not when the disk is full
or any other error), I'll concede. 

The current situation is simply blindly mis-interpreting the intent of
the standard, and then blindly implementing that.

If you would argue that you need to point out the sillyness of the
standard to the standards commission by literally implementing it,
fine, you have my support.

Roger.

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#461049: coreutils: dd no longer reports xx+yy records in|out after sigpipe.

[Rogier Wolff]

Package: coreutils
Version: 5.97-5.3
Severity: normal



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22bm
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages coreutils depends on:
ii  libacl12.2.41-1  Access control list shared library
ii  libc6  2.3.6.ds1-13etch4 GNU C Library: Shared libraries
ii  libselinux11.32-3SELinux shared libraries

coreutils recommends no packages.

-- debconf-show failed

If you do 

dd if=somebigfile | dd count=100 of=/dev/null 

both dd's should report that they copied 100 records. This worked in
debian sarge. Debian Etch, the first dd stopped reporting the number
of records copied. The script I wrote then stopped working. 
(The above is an example, my script of course used something else
than dd count=100 to limit the size copied.)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457638: confused by router that always responds as the destination host

[Rogier Wolff]

On Mon, Dec 24, 2007 at 03:46:02PM -0500, Joey Hess wrote:
 Robert Woodcock wrote:
  On Mon, Dec 24, 2007 at 10:07:47AM -0500, Joey Hess wrote:
   ICMP (-I) works, TCP SYN (-T) doesn't.

First, 

This router is completely broken. It foges packets from the
destination. As everybody else does it differently I'm pretty sure you
can find an RFC that tells you this is wrong. 

We can't program against all possible router faults. 


How traceroute decides that it reaches the destination I don't
remember. Traceroute however takes ages: It sends out one packet, 
waits for the result or times out, and then tries the next hop. 
(after trying the same hop 3 times). 

Mtr tries to do things a bit more parallel. This means that it sends
out request for multiple hops at once. It determins it's reached the
destination when at a certain hop, it gets back a reply from the
destination. This is exactly what you've seen. 

In practise, we COULD probably detect this situation: mtr sends out
requests for 5 hops further than it knows it is reasonable. So the
first round, it sends out a request for hops 1 through 5. If it then
gets a reply from hop 4, it will in the next round probe for 1 through
9. On the other hand, it concludes it reached the destination on the
reply to the first probe. This probably happens before the probe for
hop 2 goes out (at 200ms). 


Although you might want different results, mtr is behaving as
designed, and the fact that you get odd results is the fault of
your odd network, and not mtr's. 



Roger.

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384926: mtr: Broken IPv6 reverse lookup

[Rogier Wolff]

Hi Bernhard, 

The patch was already in my source, 0.72 will have this, I just
haven't released it yet.

Roger. 


On Mon, Aug 28, 2006 at 01:11:59AM +0200, Bernhard Schmidt wrote:
 Package: mtr
 Severity: normal
 Tags: patch
 
 
 mtr 0.71 breaks on certain conditions when composing the reverse nibble
 format to send to the nameserver. This leads to no (or sometimes) incorrect
 hostnames for a variety of hops.
 
 A full description and patch is available in the Fedora Core ticket system
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195458
 
 This bug has been reported to the mtr maintainer, but was not acted upon
 yet.
 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.16-iabg-pe750
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 
 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384444: mtr in sarge eats 100% cpu with -n

[Rogier Wolff]

Hi,

It is also already in my tree. 

Roger. 

On Thu, Aug 24, 2006 at 11:11:30AM +0200, Peter Palfrader wrote:
 Package: mtr-tiny
 Version: 0.67-1
 
 Hi,
 
 mtr in sarge eats 100% CPU when called with -n (don't resolve IP
 addresses to hostnames).  It turns out there is a small bug in
 select.c's select_loop() that causes select to always be called with a
 timeout of 0.
 
 The fix appears quite trivial, and already is in the version in sid:
 
 diff -w -u mtr-0.67-1/select.c mtr-0.67-1.weasel/select.c
 --- mtr-0.67-1/select.c   2004-08-26 09:56:53.0 +0200
 +++ mtr-0.67-1.weasel/select.c2006-08-24 11:08:23.290440926 +0200
 @@ -116,12 +116,14 @@
 selecttime.tv_usec += 100;
   }
  
 + if (dns) {
   if ((selecttime.tv_sec  (time_t)dnsinterval) ||
   ((selecttime.tv_sec == (time_t)dnsinterval) 
(selecttime.tv_usec  ((time_t)(dnsinterval * 100) % 
 100 {
 selecttime.tv_sec = (time_t)dnsinterval;
 selecttime.tv_usec = (time_t)(dnsinterval * 100) % 100;
   }
 + }
  
   rv = select(maxfd, (void *)readfd, NULL, NULL, selecttime);
}
 
 
 Is this something that should and could be fixed for the next stable
 point release?
 
 Cheers,
 Peter
 -- 
|  .''`.  ** Debian GNU/Linux **
   Peter Palfrader  | : :' :  The  universal
  http://www.palfrader.org/ | `. `'  Operating System
|   `-http://www.debian.org/
 
 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#329745: mtr-tiny: Contradictory output when there is a failure in name resolution

[Rogier Wolff]

On Sun, Oct 02, 2005 at 08:54:49AM -0700, Robert Woodcock wrote:
 On Sun, Oct 02, 2005 at 01:32:48AM -0300, Nelson A. de Oliveira wrote:
  On 9/27/05, Rogier Wolff [EMAIL PROTECTED] wrote:
   Yes, somehow, it calls a function that fails, but the errno variable
   indicates no specification as to what system call when wrong or why: The
   system calls all worked, just the name server told can't resolve this.
  
   I agree it's confusing. I'm not familiar with the code  that
   generates that message.
  
  Maybe forward this to upstream and change severity to wishlist?
 
 Well, you already have an answer from Rogier, who *is* upstream.
 
 The weird thing is, *neither* the Temporary failure in name resolution
 string nor the Success string appear anywhere in mtr source. Just about
 all of the DNS code returns responses that start with Resolver: or
 Resolver error: So it's a bit difficult to figure out exactly what sort of
 DNS response causes that message to appear (and therefore, what code path is
 being taken within mtr).
 
 One exception to that is this chunk in mtr.c line 392ish:
 
 #ifdef ENABLE_IPV6
   /* gethostbyname2() is deprecated so we'll use getaddrinfo() instead. */
   bzero( hints, sizeof hints );
   hints.ai_family = af;
   hints.ai_socktype = SOCK_DGRAM;
   error = getaddrinfo( Hostname, 0, hints, res );
   if ( error ) {
 perror( gai_strerror(error) );
 exit( EXIT_FAILURE );
   }
 
 
 I'm not sure that gai_strerror should be wrapped in perror like that - it
 could be that getaddrinfo does not set errno, or it could also be that
 gai_strerror resets errno. I think that a safer thing to do would be to
 check if error == EAI_SYSTEM. If so, use the output from perror. If not, use
 the output from gai_strerror. But never use the output from both.
 
 To get to the bottom of it we'd need to be able to replicate the bug. Would
 you be able to tell us how to configure a DNS server to be broken like yours
 was?

Robert, It certainly looks as if code like this is the culprit. Yes, the
Success string comes from 
errno = 0;
perror ();

Roger. 


 -- 
 Robert Woodcock - [EMAIL PROTECTED] 
 By metaphorically, I mean get in the car.
   -- Bender

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#327043: [sane-devel] LiDE 25 issues

[Rogier Wolff]

On Thu, Sep 08, 2005 at 04:30:40PM +0200, Julien BLACHE wrote:
 Gerhard Jaeger [EMAIL PROTECTED] wrote:
 
 Hi,
 
  well that what I was afraid of. The driver needs
  some tweaking either at the overall clock-divider settings
  or the motor-speed stuff. I have no possibility to check
  as I don't have that device.
 
 Thanks Gerhard, maybe the submitter can do some tests ?

Sure, I could do that. 

One of you needs to help me a bit in how to easily and quickly compile
and test a new version. 

I have the debian sources in ~/xxx/sane-backends-1.0.16 and when I
typed something like debbuild I got a libsane_1.0.16-1_i386.deb
. However, I have the impression that if I go and change a source file
in there, and do the debbuild again, it will untar and patch the
source files again, and undo my changes. Moreover, the build takes
quite a while, even though I have a reasonably powerful
workstation. So I would like to do make somewhere, so that make
will figure out that only backends/plustek-usb.c has been changed, and
that it only needs to rebuild from there. I'm happy then manuall
copying over the .so file into my system directory.

Tell me which parameters are most likely to need tweaking 

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#327044: Libsane: Extra noise on lide25 scanner.

[Rogier Wolff]

Package: libsane
Version: 1.0.16
Severity: minor

The Canoscan LiDE25 scanner makes more noise using the Linux driver
than when used under Windows. This might impact longlivety of the 
hardware?

(Driver: plustek)


-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#327043: Libsane doesn't scan at 75dpi (or lower?) on Lide25.

[Rogier Wolff]

Package: libsane
Version: 1.0.16

When I scan with scanimage at 75 DPI, the scan-element doesn't
move. It scans the black part of the enclosure. resulting images
are quite black and useless. I've decided I don't want any 75 DPI
scans, so for me this is a very low-priority bug. 
 
I've compiled 1.0.16 myself from the debian package. 1.0.16 includes
the add-lide25-support patch. This is on sarge which natively has
1.0.15. 

I suspect that one of the max motor speed settings is incorrect (too 
high) (wether that means a higher or lower number in the table I don't
know). Or maybe the driver (Plustek) needs to do some math, to reduce
the speed on low-res scans. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319968: mtr-tiny: TTL of 30 is insufficient for some routes

[Rogier Wolff]

Hi, 

How about -m maxttl or --max-ttl maxttl .

Roger. 

On Tue, Jul 26, 2005 at 11:24:35AM +1000, Konstantin Seiler wrote:
 Package: mtr-tiny
 Version: 0.67-1
 Severity: normal
 
 mtr uses a maxTTL of 30 hops. However, today there are longer routes on the
 net.
 
 Today linux's default ttl is 64. Mtr should support this by either setting
 maxTTL to a higher value (in mtr.c) or by offering a commandline option to
 manually raise this value. (like traceroute does)
 
 -- System Information:
 Debian Release: 3.1
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: i386 (i686)
 Kernel: Linux 2.6.9kms4
 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
 
 Versions of packages mtr-tiny depends on:
 ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries 
 an
 ii  libncurses5 5.4-4Shared libraries for terminal 
 hand
 
 -- no debconf information
 
 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#291850: Ogle gets screen aspect ratio wrong.

[Rogier Wolff]

Package: Ogle
Version 0.9.2-2


Ogle gets my screen aspect ratio completely wrong. It results in a very
skinny ogle window. 

I have 3 1024x768 monitors configured side-by-side, so the widht of my
screen is 90.6 cm, and the height about 23.2 cm That's correct. But if
you reason that way, the horizontal pixels should be 3072. 

when running ogle with --debug I get:

Debug[ogle_vout]: set_sync_point()
Note[ogle_vout]: using default config for ':0.0'
Note[ogle_vout]: Using 'X11' as source for geometry
Note[ogle_vout]: Using 'Xinerama' as source for resolution
Note[ogle_vout]: Display w: 906, h: 232, hp: 1024, vp: 768
^^
Note[ogle_vout]: Display sar: 237568/695808 = 0.341428
Note[ogle_vout]: Found 4 matching visuals, using visual id: 23
Note[ogle_vout]: Found Xv extension 2.2, checking for suitable adaptors
Note[ogle_vout]: Xv adaptor Matrox G-Series Backend Scaler port 61 image 
format 842094169
Debug[ogle_vout]: resize: 349, 768
Debug[ogle_vout]: resize: 349, 766


Someone with more XV, xinerama and such knowledge should look into
this, to decide which one is wrong. I'm guessing that the w and h
parameters are gotten from a slightly different place than hp and
vp so that they don't match.

For my own purposes I'm guessing that after putting w /= 3; to 
the right spot in 
./mpeg2_video/video_output_x11.c

I'll be a happy man :-)

(I'm Using debian-sarge). 

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#291850: Ogle gets screen aspect ratio wrong.

[Rogier Wolff]

On Mon, Jan 24, 2005 at 12:02:11AM +0100, Martin Norb?ck wrote:
 On Sun, Jan 23, 2005 at 05:49:27PM +0100, Rogier Wolff wrote:
  I have 3 1024x768 monitors configured side-by-side, so the widht of my
  screen is 90.6 cm, and the height about 23.2 cm That's correct. But if
  you reason that way, the horizontal pixels should be 3072. 
 
 You can fix this in oglerc.
 
 Change geometry_src from 'X11' to 'user'
 Set the width and height of the monitor you want to watch on
 in geometry with width and heigth.
 For a 4:3 monitor you can use something like:
  geometry
   width400/width
   height300/height
  /geometry
 
 Getting these things right with xinerama is tricky.

Ok. That seems to work. Thanks!.

So Ogle gets the resolution from one place, and the geometry from
anohter? Couldn't that be fixed so that it's consistent?

Xdpyinfo reports: 

screen #0:
  dimensions:3072x768 pixels (906x232 millimeters)
  resolution:86x84 dots per inch

which gives just about the right aspect ratio... Somewhere Ogle is
trying to be smart, possibly working around a bug in older Xserver
where the size would be misreported or something.

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#290215: Improper copyright file

[Rogier Wolff]

On Wed, Jan 12, 2005 at 07:19:57PM -0500, Justin Pryzby wrote:
 Package: mtr-tiny
 Version: 0.67-1
 Severity: normal
 
 The copyright file of this package seems to use the *license*, instead
 of the copyright holder in the style of Copyright (C) 2005 by Justin
 Pryzby.

Where did you find this suspicious wording? I just spent 5 minutes
looking at all the sources, but nowhere do I see the bad wording. 

Note that the COPYING file is /THE/ GPL, and is binary identical to 
most other copies floating around on the net. 

Roger. 

 Please see this thread:
 
   http://lists.debian.org/debian-devel/2004/03/msg02190.html
 
 -- System Information:
 Debian Release: 3.1
   APT prefers testing
   APT policy: (101, 'testing'), (99, 'unstable'), (9, 'experimental')
 Architecture: i386 (i686)
 Kernel: Linux 2.6.10Y
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 
 Versions of packages mtr-tiny depends on:
 ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries 
 an
 ii  libncurses5 5.4-4Shared libraries for terminal 
 hand
 
 -- no debconf information
 
 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]