Bug#891956: Your mail

2018-03-09 Thread William L. DeRieux IV 

On Fri, 9 Mar 2018 20:07:32 -0500 "William L. DeRieux IV" wrote:
> after editing /etc/eclipse.ini
> and adding -debug to it
>
> I get the following output (when running eclipse):
> -
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m;
> support was removed in 8.0
> Install location:
>     file:/usr/lib/eclipse/
> Configuration file:
>     file:/usr/lib/eclipse/configuration/config.ini loaded
> Configuration location:
> 
file:/home/william/.eclipse/org.eclipse.platform_3.8_155965261/configuration/

> Configuration file:
> 
file:/home/william/.eclipse/org.eclipse.platform_3.8_155965261/configuration/config.ini 


> not found or not read
> Shared configuration location:
>     file:/usr/lib/eclipse/configuration/
> Framework located:
> file:/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
> Framework classpath:
> Splash location:
> /usr/lib/eclipse//plugins/org.eclipse.platform_3.8.1.dist/splash.bmp
> -
>
> And the error message written to the log file:
>
> -
> !SESSION Fri Mar 09 20:00:00 EST 2018
> !ENTRY org.eclipse.equinox.launcher 4 0 2018-03-09 20:00:00.374
> !MESSAGE Exception launching the Eclipse Platform:
> !STACK
> java.lang.ClassNotFoundException:
> org.eclipse.core.runtime.adaptor.EclipseStarter
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>     at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:626)
>     at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
>     at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
>     at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
>
>
> -
>
> It seems that this error is happening because the framework's class path
> is not being properly set (hence it can't find the class).
>
>
>


I resolved this issue (on my system) by reinstalling libequinox

$ sudo apt-get install --reinstall libequinox-osgi-java

The debug output claimed that the framework has been found, but this was 
a lie since:

/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar was missing.

Maybe there needs to be better sanity checking here.

Bug#891956: (no subject)

2018-03-09 Thread William L. DeRieux IV 

after editing /etc/eclipse.ini
and adding -debug to it

I get the following output (when running eclipse):
-
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
support was removed in 8.0

Install location:
    file:/usr/lib/eclipse/
Configuration file:
    file:/usr/lib/eclipse/configuration/config.ini loaded
Configuration location:
file:/home/william/.eclipse/org.eclipse.platform_3.8_155965261/configuration/
Configuration file:
file:/home/william/.eclipse/org.eclipse.platform_3.8_155965261/configuration/config.ini 
not found or not read

Shared configuration location:
    file:/usr/lib/eclipse/configuration/
Framework located:
    file:/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
Framework classpath:
Splash location:
/usr/lib/eclipse//plugins/org.eclipse.platform_3.8.1.dist/splash.bmp
-

And the error message written to the log file:

-
!SESSION Fri Mar 09 20:00:00 EST 2018
!ENTRY org.eclipse.equinox.launcher 4 0 2018-03-09 20:00:00.374
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.ClassNotFoundException: 
org.eclipse.core.runtime.adaptor.EclipseStarter

    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:626)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1414)


-

It seems that this error is happening because the framework's class path
is not being properly set (hence it can't find the class).

Bug#891956: updating found version

2018-03-09 Thread William L. DeRieux IV 

found 891956 3.8.1-10

Bug#854357: valgrind error report

2017-02-15 Thread William L. DeRieux IV 

Using valgrind to execute monodeveop gave me some more information and

it seems to be an issue (free() invalid pointer as well as double free 
or corruption) in gtk_file_chooser_get_filenames.


$ valgrind mono-sgen --debug /usr/lib/monodevelop/bin/MonoDevelop.exe

==21563== Conditional jump or move depends on uninitialised value(s)
==21563==at 0x33B313: sgen_conservatively_pin_objects_from 
(sgen-gc.c:841)

==21563==by 0x3219E5: sgen_client_scan_thread_data (sgen-mono.c:2391)
==21563==by 0x33C824: collect_nursery.part.27.constprop.33 
(sgen-gc.c:1563)

==21563==by 0x33EF49: collect_nursery (sgen-gc.c:2246)
==21563==by 0x33EF49: sgen_perform_collection (sgen-gc.c:2266)
==21563==by 0x331B43: sgen_alloc_obj_nolock (sgen-alloc.c:262)
==21563==by 0x331FF5: sgen_alloc_obj (sgen-alloc.c:426)
==21563==by 0x31D408: mono_gc_alloc_obj (sgen-mono.c:930)
==21563==by 0x4045297: ???
==21563==by 0x67FFE67: ???
==21563==by 0x5D6049F: ???
==21563==by 0x5D5FF7F: ???
==21563==by 0xB18ED5F: ???
==21563==
==21563== Conditional jump or move depends on uninitialised value(s)
==21563==at 0x33B318: sgen_conservatively_pin_objects_from 
(sgen-gc.c:841)

==21563==by 0x3219E5: sgen_client_scan_thread_data (sgen-mono.c:2391)
==21563==by 0x33C824: collect_nursery.part.27.constprop.33 
(sgen-gc.c:1563)

==21563==by 0x33EF49: collect_nursery (sgen-gc.c:2246)
==21563==by 0x33EF49: sgen_perform_collection (sgen-gc.c:2266)
==21563==by 0x331B43: sgen_alloc_obj_nolock (sgen-alloc.c:262)
==21563==by 0x331FF5: sgen_alloc_obj (sgen-alloc.c:426)
==21563==by 0x31D408: mono_gc_alloc_obj (sgen-mono.c:930)
==21563==by 0x4045297: ???
==21563==by 0x67FFE67: ???
==21563==by 0x5D6049F: ???
==21563==by 0x5D5FF7F: ???
==21563==by 0xB18ED5F: ???
==21563==
==21563== Conditional jump or move depends on uninitialised value(s)
==21563==at 0x14796259: compute_hint (pixbuf-render.c:606)
==21563==by 0x14796259: theme_pixbuf_compute_hints (pixbuf-render.c:696)
==21563==by 0x14797047: theme_pixbuf_get_pixbuf (pixbuf-render.c:759)
==21563==by 0x147970F2: theme_pixbuf_render (pixbuf-render.c:777)
==21563==by 0x14793E09: draw_simple_image.isra.0 (pixbuf-draw.c:145)
==21563==by 0x14794B01: draw_flat_box (pixbuf-draw.c:699)
==21563==by 0xC90F68C: gtk_entry_expose (gtkentry.c:3450)
==21563==by 0x228FCF5A: ???
==21563==by 0x1F68D26B: ???
==21563==by 0xC97E7BB: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:86)
==21563==by 0xEE0BF74: g_closure_invoke (gclosure.c:804)
==21563==by 0xEE1E37C: signal_emit_unlocked_R (gsignal.c:3673)
==21563==by 0xEE2666E: g_signal_emit_valist (gsignal.c:3401)
==21563==
==21563== Conditional jump or move depends on uninitialised value(s)
==21563==at 0x10616FBE: ??? (in 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0)
==21563==by 0x105FAE1A: ??? (in 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0)
==21563==by 0x105B66E0: pixman_image_composite32 (in 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0)
==21563==by 0xE10069A: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE145999: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE137C3D: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE1386B2: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE1395C2: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE0F3BAF: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE1052C6: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE13C816: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE0FC28B: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)

==21563==
==21563== Conditional jump or move depends on uninitialised value(s)
==21563==at 0x10616FBE: ??? (in 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0)
==21563==by 0x105FAE1A: ??? (in 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0)
==21563==by 0x105B66E0: pixman_image_composite32 (in 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0)
==21563==by 0xE10073A: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE145999: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE137C3D: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE1386B2: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE1395C2: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE0F3BAF: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE1052C6: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE13C816: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)
==21563==by 0xE0FC28B: ??? (in 
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.8)

==21563==
==21563==

Bug#854357: monodevelop crashes when shortly after the openfile dialog is shown

2017-02-07 Thread William L. DeRieux IV 
When running a flatpak for v6.1.4 of monodevelop -- the crashing when 
opening files/solutions no longer occurs.


$ sudo apt-get install flatpak
$ flatpak install --user --from 
https://download.mono-project.com/repo/monodevelop.flatpakref

$ flatpak run com.xamarin.MonoDevelop

MonoDevelop
Version 6.1.4
Installation UUID: e01eb57a-5c6c-45aa-8fec-f26514c759af
Runtime:
Mono 4.6.2 ((HEAD/ac9e222 Thu Jan 12 10:04:22 UTC 2017) (64-bit)
GTK+ 2.24.29 (Adwaita theme)

NuGet
Version: 3.4.3.0

Build Information
e606823f2dd01b4552216c013b597a73bec2068f

Operating System
Linux
Linux desktop1 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) 
x86_64 GNU/Linux


On Mon, 06 Feb 2017 06:12:52 -0500 "William L. DeRieux IV" wrote:
> Package: monodevelop
> Version: 5.10.0.871-2
> Severity: important
>
> When using MonoDevelop 5.10.0.871-2 / mono 4.6.2.7+dfsg-1 and I try 
to open a

> file or a project I get the following error.
> It does not crash immediately but it does so after a short time (1-5 
seconds).

>
> $ apt-cache policy monodevelop
> *** 5.10.0.871-2
> $ apt-cache policy mono-runtime-sgen
> *** 4.6.2.7+dfsg-1
>
> $ gdb --args mono-sgen /usr/lib/monodevelop/bin/MonoDevelop.exe
> -
> *** Error in `/usr/bin/mono-sgen': free(): invalid pointer: 
0x57ac1e90

> ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x76f67bcb]
> /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x76f6df96]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7778e)[0x76f6e78e]
> [0x40326d50]
> === Memory map: 
> 4000-40334000 rwxp  00:00 0
> 4000-558f1000 r-xp  08:11 24194679
> /usr/bin/mono-sgen
> 55af-55af5000 r--p 0039c000 08:11 24194679
> /usr/bin/mono-sgen
> 55af5000-55aff000 rw-p 003a1000 08:11 24194679
> /usr/bin/mono-sgen
> 55aff000-57c53000 rw-p  00:00 0 [heap]
> 7fff8c00-7fff8c022000 rw-p  00:00 0
> 7fff8c022000-7fff9000 ---p  00:00 0
> 7fff9400-7fff94022000 rw-p  00:00 0
> [...snipped...]
> 77faa000-77fe8000 rw-p  00:00 0
> 77fe8000-77fed000 rw-p  00:00 0
> 77fed000-77fee000 r--p  08:11 9888151
> /usr/lib/monodevelop/bin/MonoDevelop.exe
> 77fee000-77ff4000 rw-p  00:00 0
> 77ff4000-77ff5000 rw-s  00:11 486507
> /dev/shm/mono.26449
> 77ff5000-77ff8000 rw-p  00:00 0
> 77ff8000-77ffa000 r-xp  00:00 0 [vdso]
> 77ffa000-77ffc000 r--p  00:00 0 [vvar]
> 77ffc000-77ffd000 r--p 00023000 08:11 16302211
> /lib/x86_64-linux-gnu/ld-2.24.so
> 77ffd000-77ffe000 rw-p 00024000 08:11 16302211
> /lib/x86_64-linux-gnu/ld-2.24.so
> 77ffe000-77fff000 rw-p  00:00 0
> 7f80-7f808000 ---p  00:00 0
> 7ffde000-7000 rw-p  00:00 0
> [stack]
> ff60-ff601000 r-xp  00:00 0
> [vsyscall]
>
> Thread 3 "Finalizer" received signal SIGABRT, Aborted.
> [Switching to Thread 0x74434700 (LWP 26454)]
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
> 58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Bug#854357: monodevelop crashes when shortly after the openfile dialog is shown

2017-02-06 Thread William L. DeRieux IV 
Package: monodevelop
Version: 5.10.0.871-2
Severity: important

When using MonoDevelop 5.10.0.871-2 / mono 4.6.2.7+dfsg-1 and I try to open a
file or a project I get the following error.
It does not crash immediately but it does so after a short time (1-5 seconds).

$ apt-cache policy monodevelop
*** 5.10.0.871-2
$ apt-cache policy mono-runtime-sgen
*** 4.6.2.7+dfsg-1

$ gdb --args mono-sgen /usr/lib/monodevelop/bin/MonoDevelop.exe
-
*** Error in `/usr/bin/mono-sgen': free(): invalid pointer: 0x57ac1e90
***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x76f67bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x76f6df96]
/lib/x86_64-linux-gnu/libc.so.6(+0x7778e)[0x76f6e78e]
[0x40326d50]
=== Memory map: 
4000-40334000 rwxp  00:00 0
4000-558f1000 r-xp  08:11 24194679
/usr/bin/mono-sgen
55af-55af5000 r--p 0039c000 08:11 24194679
/usr/bin/mono-sgen
55af5000-55aff000 rw-p 003a1000 08:11 24194679
/usr/bin/mono-sgen
55aff000-57c53000 rw-p  00:00 0  [heap]
7fff8c00-7fff8c022000 rw-p  00:00 0
7fff8c022000-7fff9000 ---p  00:00 0
7fff9400-7fff94022000 rw-p  00:00 0
[...snipped...]
77faa000-77fe8000 rw-p  00:00 0
77fe8000-77fed000 rw-p  00:00 0
77fed000-77fee000 r--p  08:11 9888151
/usr/lib/monodevelop/bin/MonoDevelop.exe
77fee000-77ff4000 rw-p  00:00 0
77ff4000-77ff5000 rw-s  00:11 486507
/dev/shm/mono.26449
77ff5000-77ff8000 rw-p  00:00 0
77ff8000-77ffa000 r-xp  00:00 0  [vdso]
77ffa000-77ffc000 r--p  00:00 0  [vvar]
77ffc000-77ffd000 r--p 00023000 08:11 16302211
/lib/x86_64-linux-gnu/ld-2.24.so
77ffd000-77ffe000 rw-p 00024000 08:11 16302211
/lib/x86_64-linux-gnu/ld-2.24.so
77ffe000-77fff000 rw-p  00:00 0
7f80-7f808000 ---p  00:00 0
7ffde000-7000 rw-p  00:00 0
[stack]
ff60-ff601000 r-xp  00:00 0
[vsyscall]

Thread 3 "Finalizer" received signal SIGABRT, Aborted.
[Switching to Thread 0x74434700 (LWP 26454)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
58  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x76f29fdf in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:58
#1  0x76f2b40a in __GI_abort () at abort.c:89
#2  0x76f67bd0 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7705cc30 "*** Error in `%s': %s: 0x%s ***\n") at
../sysdeps/posix/libc_fatal.c:175
#3  0x76f6df96 in malloc_printerr (action=3, str=0x770597cd
"free(): invalid pointer", ptr=, ar_ptr=) at
malloc.c:5046
#4  0x76f6e78e in _int_free (av=0x7728fb00 ,
p=0x57ac1e80, have_lock=0) at malloc.c:3902
#5  0x40326d50 in  ()
#6  0x57ac1e90 in  ()
#7  0x55b554b0 in  ()
#8  0x55b554b0 in  ()
#9  0x in  ()



-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (1001, 'testing-debug'), (1001, 'testing'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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 monodevelop depends on:
ii  gnome-icon-theme  3.12.0-2
ii  gnome-terminal [x-terminal-emulator]  3.22.1-1
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libfontconfig12.11.0-6.7
ii  libgconf2.0-cil   2.24.2-4
ii  libglade2.0-cil   2.12.40-1
ii  libglib2.0-0  2.50.2-2
ii  libglib2.0-cil2.12.40-1
ii  libgnome-vfs2.0-cil   2.24.2-4
ii  libgnome2.24-cil  2.24.2-4
ii  libgtk2.0-0   2.24.31-2
ii  libgtk2.0-cil 2.12.40-1
ii  libgtkspell0  2.0.16-1.1
ii  libmono-cairo4.0-cil  4.6.2.7+dfsg-1
ii  libmono-corlib4.5-cil 4.6.2.7+dfsg-1
ii  libmono-microsoft-build-engine4.0-cil 4.6.2.7+dfsg-1
ii  libmono-microsoft-build-framework4.0-cil  4.6.2.7+dfsg-1
ii  libmono-microsoft-build-utilities-v4.0-4.0-cil4.6.2.7+dfsg-1
ii  libmono-microsoft-csharp4.0-cil

Bug#851518: cinnamon won't start

2017-01-19 Thread William L. DeRieux IV 

tags 851518 = moreinfo unreproducible

--

On Thu, 19 Jan 2017 16:14:08 -0500 "William L. DeRieux IV" wrote:
> On Tue, 17 Jan 2017 22:43:42 +0100 Carsten Kosthorstwrote:
>
> > Hi,
> >
> > I updated today and cinnamon is working again.
> >
> > Thanks,
> >
> > Carsten
> >
> >
> >
>
> Your version of cinnamon was 3.2.7-1 in the initial report.
>
> The latest version in unstable/sid is 3.2.7-1.
>
> What version was cinnamon updated to the second time?
>
> You can do this by using: *apt-cache policy cinnamon*
>
> The latest version in stretch/sid is 3.2.7-1, so I'm thinking this issue
> was temporary ?
>
>

I just updated to 3.2.7-1 and I cannot reproduce this issue.

So this does seem to be a one-off issue.

Bug#851518: cinnamon won't start

2017-01-19 Thread William L. DeRieux IV 
tags 851518 - moreinfo-- 
On Tue, 17 Jan 2017 22:43:42 +0100 Carsten Kosthorstwrote:


> Hi,
>
> I updated today and cinnamon is working again.
>
> Thanks,
>
> Carsten
>
>
>

Your version of cinnamon was 3.2.7-1 in the initial report.

The latest version in unstable/sid is 3.2.7-1.

What version was cinnamon updated to the second time?

You can do this by using: *apt-cache policy cinnamon*

The latest version in stretch/sid is 3.2.7-1, so I'm thinking this issue 
was temporary ?

Bug#674827: Gdb backtrace against latest version of scim/1.4.17-1 using Gimp 2.8.18-1

2016-12-03 Thread William L. DeRieux IV 

--
Gdb backtrace against latest version of scim/1.4.17-1 using Gimp 2.8.18-1

(gimp:16410): Gdk-WARNING **: 
/build/gtk+2.0-pW7LUB/gtk+2.0-2.24.31/gdk/x11/gdkdrawable-x11.c:874 
drawable is not a pixmap or window



Thread 1 "gimp" received signal SIGSEGV, Segmentation fault.
0x771fc878 in IA__gdk_x11_drawable_get_xdisplay 
(drawable=0x5867cad0 [GdkOffscreenWindow]) at 
./gdk/x11/gdkdrawable-x11.c:908

908./gdk/x11/gdkdrawable-x11.c: No such file or directory.
(gdb) bt
#0  0x771fc878 in IA__gdk_x11_drawable_get_xdisplay 
(drawable=0x5867cad0 [GdkOffscreenWindow]) at 
./gdk/x11/gdkdrawable-x11.c:908
#1  0x7fffd3df2e2e in scim_bridge_key_event_gdk_to_bridge () at 
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-scim.so
#2  0x7fffd3df27b1 in  () at 
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-scim.so
#3  0x7fffd3df2a74 in  () at 
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-scim.so
#4  0x77575933 in gtk_im_multicontext_filter_keypress 
(context=0x58571c30 [GtkIMMulticontext], event=0x5847c090) at 
./gtk/gtkimmulticontext.c:333
#5  0x77522b3c in gtk_entry_key_press 
(widget=widget@entry=0x56a89cd0 [GtkSpinButton], 
event=0x5847c090) at ./gtk/gtkentry.c:4073
#10 0x73d44faf in [GtkSpinButton]> (instance=instance@entry=0x56a89cd0, 
signal_id=, detail=detail@entry=0)

at ././gobject/gsignal.c:3447
#6  0x7758c84c in _gtk_marshal_BOOLEAN__BOXED 
(closure=0x55ed1130, return_value=0x7fffd3f0, 
n_param_values=, param_values=0x7fffd450, 
invocation_hint=, marshal_data=) at 
./gtk/gtkmarshalers.c:86
#7  0x73d29ecf in g_closure_invoke 
(closure=closure@entry=0x55ed1130, 
return_value=return_value@entry=0x7fffd3f0, n_param_values=2, 
param_values=param_values@entry=0x7fffd450, 
invocation_hint=invocation_hint@entry=0x7fffd3d0) at 
././gobject/gclosure.c:804
#8  0x73d3c37d in signal_emit_unlocked_R 
(node=node@entry=0x55ed1400, detail=detail@entry=0, 
instance=instance@entry=0x56a89cd0, 
emission_return=emission_return@entry=0x7fffd560, 
instance_and_params=instance_and_params@entry=0x7fffd450) at 
././gobject/gsignal.c:3673
#9  0x73d4466f in g_signal_emit_valist (instance=out>, signal_id=, detail=, 
var_args=var_args@entry=0x7fffd610)

at ././gobject/gsignal.c:3401
#11 0x776a498c in gtk_widget_event_internal 
(widget=widget@entry=0x56a89cd0 [GtkSpinButton], 
event=event@entry=0x5847c090) at ./gtk/gtkwidget.c:5010
#12 0x776a4c57 in IA__gtk_widget_event 
(widget=widget@entry=0x56a89cd0 [GtkSpinButton], 
event=event@entry=0x5847c090) at ./gtk/gtkwidget.c:4807
#13 0x776b83bf in IA__gtk_window_propagate_key_event 
(window=0x7fffe0ac1450 [GimpImageWindow], event=0x5847c090) at 
./gtk/gtkwindow.c:5199

#14 0x5577ee6b in  ()
#19 0x73d44faf in [GimpImageWindow]> (instance=instance@entry=0x7fffe0ac1450, 
signal_id=, detail=detail@entry=0)

at ././gobject/gsignal.c:3447
#15 0x7758c84c in _gtk_marshal_BOOLEAN__BOXED 
(closure=0x55ed1130, return_value=0x7fffd940, 
n_param_values=, param_values=0x7fffd9a0, 
invocation_hint=, marshal_data=) at 
./gtk/gtkmarshalers.c:86
#16 0x73d29f75 in g_closure_invoke 
(closure=closure@entry=0x55ed1130, 
return_value=return_value@entry=0x7fffd940, n_param_values=2, 
param_values=param_values@entry=0x7fffd9a0, 
invocation_hint=invocation_hint@entry=0x7fffd920) at 
././gobject/gclosure.c:804
#17 0x73d3c37d in signal_emit_unlocked_R 
(node=node@entry=0x55ed1400, detail=detail@entry=0, 
instance=instance@entry=0x7fffe0ac1450, 
emission_return=emission_return@entry=0x7fffdab0, 
instance_and_params=instance_and_params@entry=0x7fffd9a0) at 
././gobject/gsignal.c:3673
#18 0x73d4466f in g_signal_emit_valist (instance=out>, signal_id=, detail=, 
var_args=var_args@entry=0x7fffdb60)

at ././gobject/gsignal.c:3401
#20 0x776a498c in gtk_widget_event_internal 
(widget=widget@entry=0x7fffe0ac1450 [GimpImageWindow], 
event=event@entry=0x5847c090) at ./gtk/gtkwidget.c:5010
#21 0x776a4c57 in IA__gtk_widget_event 
(widget=widget@entry=0x7fffe0ac1450 [GimpImageWindow], 
event=event@entry=0x5847c090) at ./gtk/gtkwidget.c:4807
#22 0x7758b0ef in IA__gtk_propagate_event (widget=0x7fffe0ac1450 
[GimpImageWindow], event=0x5847c090) at ./gtk/gtkmain.c:2475
#23 0x7758b3cb in IA__gtk_main_do_event (event=0x5847c090) 
at ./gtk/gtkmain.c:1696
#24 0x77200cec in gdk_event_dispatch (source=, 
callback=, user_data=) at 
./gdk/x11/gdkevents-x11.c:2425
#25 0x7384e7f7 in g_main_context_dispatch 
(context=0x55e92910) at ././glib/gmain.c:3203
#26 0x7384e7f7 in g_main_context_dispatch 
(context=context@entry=0x55e92910) at ././glib/gmain.c:3856
#27 0x7384ea60 in g_main_context_iterate

Bug#842841: [pkg-cinnamon] Bug#842841: Bug#842841: cinnamon: Runing cinnamon --replace segfaults after recent update

2016-11-03 Thread William L. DeRieux IV 

On Thu, 3 Nov 2016 11:06:23 +0100 Maximiliano Curia wrote:
> ¡Hola William!
>
> El 2016-11-02 a las 17:32 -0400, William L. DeRieux IV escribió:
> >>> I'm running Cinnamon 3.0.7-2 everything was fine until a recent 
update.
> >>> Now clicking on certain items on the cinnamon-panel causes a 
crash and
> >>> when running cinnamon --replace from a tty causes a segmentation 
fault.

>
> >> Can you try to narrow down the list of upgraded packaged that 
caused this?

>
> The list of upgraded packages might be useful. You can obtain this 
information

> from the /var/log/dpkg.log* files.
>
> Using snapshots.debian.org, you could downgrade the cinnamon packages 
and test
> this again to check if any of the recent changes in cinnamon causes 
the issue.

>
> Happy hacking,
> --
> "Inside every large problem is a small problem struggling to get out."
> -- Hoare's Law of Large Problems
> Saludos /\/\ /\ >< `/

Ok, here is an update to this issue.

The initial issue that I had, that prompted this, was that the 
cinnamon-panel had become non-responsive and I could not launch any 
apps, etc.
I also rebooted to ensure that is wasn't something that would have been 
fixed by a reboot.


Adfter rebooting -- the cinnamon panel was still non-responsive -- to a 
tty and ran *cinnamon --replace* which crashed (as reported).
I switched to the mate desktop to get around the issue -- at least for 
the time being.


The other day I switched back to cinnamon to re-test this and the 
cinnamon-panel was functioning correctly.


Oddly, enough running *cinnamon --replace* from a tty still crashes, but 
I was able to run it, from a terminal, within cinnamon without issues.


PS: I can't remember what date that I first experienced this -- but it 
was a few days ago -- I switched to MATE to get around

it temporarily and I reported the issue a few days later.

I guess the point is that cinnamon seems to be functioning correctly -- 
even though *cinnamon --replace* can't seem to executed

from a tty (but does not fail if run from within cinnamon).

I'm not sure if this may now be expected behavior...

Bug#842841: [pkg-cinnamon] Bug#842841: cinnamon: Runing cinnamon --replace segfaults after recent update

2016-11-02 Thread William L. DeRieux IV 

On Wed, 2 Nov 2016 11:42:54 +0100 Maximiliano Curia wrote:
> Control: tag -1 + moreinfo
>
> ¡Hola William!
>
> El 2016-11-01 a las 12:56 -0400, William L. DeRieux IV escribió:
> > Package: cinnamon
> > Version: 3.0.7-2
> > Severity: important
>
> > I'm running Cinnamon 3.0.7-2 everything was fine until a recent 
update.

> > Now clicking on certain items on the cinnamon-panel causes a crash and
> > when running cinnamon --replace from a tty causes a segmentation fault.
>
> Can you try to narrow down the list of upgraded packaged that caused 
this?

>
> > This is the output from the command and the backtrace generated by gdb:
>
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 20)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 22)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 22)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 22)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 22)
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 28)
> >
> > (cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
> > 'GVC_IS_MIXER_CARD (card)' failed
> >
> > (cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
> > 'GVC_IS_MIXER_CARD (card)' failed
> >
> > (cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
> > 'GVC_IS_MIXER_CARD (card)' failed
> >
> > (cinnamon:9796): St-WARNING **: Failed to allocate offscreen for 
texture (sized

> > 20)
>
> I haven't seen these warnings before. I guess that something broke 
within the

> nvidia driver
>
> > Thread 1 "cinnamon" received signal SIGSEGV, Segmentation fault.
> > 0x7fffeb003010 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-
> > glcore.so.367.44
> > (gdb) bt
> > #0 0x7fffeb003010 in () at /usr/lib/x86_64-linux-gnu/libnvidia-
> > glcore.so.367.44
> > #1 0x7fffeaf1a311 in () at /usr/lib/x86_64-linux-gnu/libnvidia-
> > glcore.so.367.44
> > #2 0x7fffeaf24136 in () at /usr/lib/x86_64-linux-gnu/libnvidia-
> > glcore.so.367.44

I tried using kernel 4.7 instead of 3.16, which made no difference.
I also tried several version(s) of the nvidia-driver 367.44-3 (stretch), 
367.57-1 (sid), and 370.28-1 (experimental).


In all cases gdb generated the same backtrace.

I don't think this is an issue with the nvidia-driver, as a lot more 
should have been broken by it.

Bug#842841: cinnamon: Runing cinnamon --replace segfaults after recent update

2016-11-01 Thread William L. DeRieux IV 
Package: cinnamon
Version: 3.0.7-2
Severity: important

Dear Maintainer,

I'm running Cinnamon 3.0.7-2 everything was fine until a recent update.
Now clicking on certain items on the cinnamon-panel causes a crash and
when running cinnamon --replace from a tty causes a segmentation fault.

This is the output from the command and the backtrace generated by gdb:

GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cinnamon...Reading symbols from /usr/lib/debug/.build-
id/be/08ba4f5f8382c9f3421a2588b412c88503dc03.debug...done.
done.
(gdb) run
Starting program: /usr/bin/cinnamon --replace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe2c1b700 (LWP 9800)]
[New Thread 0x7fffe241a700 (LWP 9801)]
[New Thread 0x7fffe1908700 (LWP 9802)]
[New Thread 0x7fffe1107700 (LWP 9803)]
[New Thread 0x7fffe0906700 (LWP 9804)]
[New Thread 0x7fffcb0ff700 (LWP 9807)]
Cjs-Message: JS LOG: About to start Cinnamon

(cinnamon:9796): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor
with dbus name org.gtk.vfs.GoaVolumeMonitor is not supported

(cinnamon:9796): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor
with dbus name org.gtk.vfs.GoaVolumeMonitor is not supported

(cinnamon:9796): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor
with dbus name org.gtk.vfs.GoaVolumeMonitor is not supported
St-Message: cogl npot texture sizes SUPPORTED
Cjs-Message: JS LOG: Cinnamon started at Tue Nov 01 2016 12:45:00 GMT-0400
(EDT)
[New Thread 0x7fffc97bf700 (LWP 9809)]
[New Thread 0x7fffc8dee700 (LWP 9810)]
[New Thread 0x7fffbbfff700 (LWP 9811)]
[New Thread 0x7fffbb7fe700 (LWP 9812)]
[New Thread 0x7fffbaffd700 (LWP 9813)]
[New Thread 0x7fffba7fc700 (LWP 9814)]
[New Thread 0x7fffb9ffb700 (LWP 9815)]
[New Thread 0x7fffb97fa700 (LWP 9816)]
openGL version 3.1 detected (GL3 Cogl Driver)

(cinnamon:9796): St-WARNING **: Failed to allocate offscreen for texture (sized
20)

(cinnamon:9796): St-WARNING **: Failed to allocate offscreen for texture (sized
22)

(cinnamon:9796): St-WARNING **: Failed to allocate offscreen for texture (sized
22)

(cinnamon:9796): St-WARNING **: Failed to allocate offscreen for texture (sized
22)

(cinnamon:9796): St-WARNING **: Failed to allocate offscreen for texture (sized
22)

(cinnamon:9796): St-WARNING **: Failed to allocate offscreen for texture (sized
28)

(cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
'GVC_IS_MIXER_CARD (card)' failed

(cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
'GVC_IS_MIXER_CARD (card)' failed

(cinnamon:9796): Cvc-CRITICAL **: gvc_mixer_card_get_index: assertion
'GVC_IS_MIXER_CARD (card)' failed

(cinnamon:9796): St-WARNING **: Failed to allocate offscreen for texture (sized
20)

Thread 1 "cinnamon" received signal SIGSEGV, Segmentation fault.
0x7fffeb003010 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-
glcore.so.367.44
(gdb) bt
#0  0x7fffeb003010 in  () at /usr/lib/x86_64-linux-gnu/libnvidia-
glcore.so.367.44
#1  0x7fffeaf1a311 in  () at /usr/lib/x86_64-linux-gnu/libnvidia-
glcore.so.367.44
#2  0x7fffeaf24136 in  () at /usr/lib/x86_64-linux-gnu/libnvidia-
glcore.so.367.44
#3  0x7fffeab8c799 in  () at /usr/lib/x86_64-linux-gnu/libnvidia-
glcore.so.367.44
#4  0x778c1ed7 in meta_sync_ring_insert_wait (self=0x58915370) at
compositor/meta-sync-ring.c:285
#5  0x778c1ed7 in meta_sync_ring_insert_wait () at compositor/meta-
sync-ring.c:593
#6  0x778bac35 in meta_pre_paint_func (data=0x55ec26d0) at
compositor/compositor.c:1394
#7  0x77169574 in _clutter_run_repaint_functions
(flags=flags@entry=CLUTTER_REPAINT_FLAGS_PRE_PAINT) at clutter-main.c:3449
#8  0x7716a317 in clutter_clock_dispatch (master_clock=0x56936040
[ClutterMasterClockDefault], stages=0x57e8c060)
at clutter-master-clock-default.c:437
#9  0x7716a317 in clutter_clock_dispatch (source=,
callback=, user_data=)
at clutter-master-clock-default.c:567
#10 0x764dc7d7 in g_main_context_dispatch (context=0x557bff40) at
././glib/gmain.c:3203
#11 0x764dc7d7 in g_main_context_dispatch
(context=context@entry=0x557bff40) at

Bug#841882: workaround

2016-10-24 Thread William L. DeRieux IV 

The thrown exceptions look like these:

ERROR: System.MissingMethodException: Method not found: 'Int32 
System.Runtime.InteropServices.Marshal.SizeOf(!!0)'.
ERROR: System.MissingMethodException: Method not found: 'Void 
System.Runtime.InteropServices.Marshal.StructureToPtr(!!0, IntPtr, 
Boolean)'.


 this are the faulting lines (in the code I'm working with) 
Int32 intTokenElevationSize = Marshal.SizeOf(tevTokenElevation);
Marshal.StructureToPtr(tevTokenElevation, pteTokenElevation, true);

 explicitly casting to object fixes the method not found error 
Int32 intTokenElevationSize = 
Marshal.SizeOf((object)tevTokenElevation);
Marshal.StructureToPtr((object)tevTokenElevation, 
pteTokenElevation, true);

Bug#841882: monodevelop: TargetFramework not properly generated for Mono/.NET 4.0

2016-10-24 Thread William L. DeRieux IV 
Package: monodevelop
Version: 5.10.0.871-2
Severity: important

When building a project and targeting Mono/.NET 4.0 an assemlyinfo file is
automatically generated
in the obj folder: .NETFramework\,Version\=v4.5.AssemblyAttribute.cs

The content of this file is:
// 
[assembly:
global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETFramework,Version=v4.5",
FrameworkDisplayName = "")]

When targeting Mono/.NET 4.0 the file should be named
.NETFramework\,Version\=v4.0.AssemblyAttribute.cs
---
And the content of this file should be:
// 
[assembly:
global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETFramework,Version=v4.0",
FrameworkDisplayName = "")]


as per: https://msdn.microsoft.com/en-
us/library/system.runtime.versioning.targetframeworkattribute(v=vs.110).aspx


I don't know if that alone would be enough.

I was writing some test code and targeting Mono/.Net 4.0 (I could target 4.5)
-- the fact that there are two seperate options
indicates, to me, that they are building against different runtime versions.

Under mono (and wine when targeting v4.0/v4.5) the code runs correctly.

However that some code (compiled aginst v4.0) will not execute on any system
where .Net 4.5 cannot be installed.

What happended is that (as with my code) the code (on Windows XP) would throw
missing method exceptions for
Marshal.SizeOf, Marshal.StructureToPtr, etc -- because instead of targeting
v4.0 is was actually built against v4.5.

I'm not sure if this was a bug, or intended behavior.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (1001, 'testing-debug'), (1001, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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 monodevelop depends on:
ii  gnome-icon-theme  3.12.0-2
ii  gnome-terminal [x-terminal-emulator]  3.22.0-3
ii  libc6 2.24-3
ii  libcairo2 1.14.6-1+b1
ii  libfontconfig12.11.0-6.7
ii  libgconf2.0-cil   2.24.2-4
ii  libglade2.0-cil   2.12.10-6
ii  libglib2.0-0  2.50.1-1
ii  libglib2.0-cil2.12.10-6
ii  libgnome-vfs2.0-cil   2.24.2-4
ii  libgnome2.24-cil  2.24.2-4
ii  libgtk2.0-0   2.24.31-1
ii  libgtk2.0-cil 2.12.10-6
ii  libgtkspell0  2.0.16-1.1
ii  libmono-cairo4.0-cil  4.2.1.102+dfsg2-8
ii  libmono-corlib4.5-cil 4.2.1.102+dfsg2-8
ii  libmono-microsoft-build-engine4.0-cil 4.2.1.102+dfsg2-8
ii  libmono-microsoft-build-framework4.0-cil  4.2.1.102+dfsg2-8
ii  libmono-microsoft-build-utilities-v4.0-4.0-cil4.2.1.102+dfsg2-8
ii  libmono-microsoft-csharp4.0-cil   4.2.1.102+dfsg2-8
ii  libmono-posix4.0-cil  4.2.1.102+dfsg2-8
ii  libmono-sharpzip4.84-cil  4.2.1.102+dfsg2-8
ii  libmono-system-componentmodel-dataannotations4.0-cil  4.2.1.102+dfsg2-8
ii  libmono-system-configuration4.0-cil   4.2.1.102+dfsg2-8
ii  libmono-system-core4.0-cil4.2.1.102+dfsg2-8
ii  libmono-system-data-services-client4.0-cil4.2.1.102+dfsg2-8
ii  libmono-system-data4.0-cil4.2.1.102+dfsg2-8
ii  libmono-system-design4.0-cil  4.2.1.102+dfsg2-8
ii  libmono-system-drawing4.0-cil 4.2.1.102+dfsg2-8
ii  libmono-system-numerics4.0-cil4.2.1.102+dfsg2-8
ii  libmono-system-runtime-serialization4.0-cil   4.2.1.102+dfsg2-8
ii  libmono-system-runtime4.0-cil 4.2.1.102+dfsg2-8
ii  libmono-system-security4.0-cil4.2.1.102+dfsg2-8
ii  libmono-system-servicemodel4.0a-cil   4.2.1.102+dfsg2-8
ii  libmono-system-web-mvc3.0-cil 4.2.1.102+dfsg2-8
ii  libmono-system-web-razor2.0-cil   4.2.1.102+dfsg2-8
ii  libmono-system-web-services4.0-cil4.2.1.102+dfsg2-8
ii  libmono-system-web-webpages-razor2.0-cil  4.2.1.102+dfsg2-8
ii  libmono-system-web4.0-cil 4.2.1.102+dfsg2-8
ii

Bug#840168: Slight update

2016-10-08 Thread William L. DeRieux IV 
In my example I said samba_util.h from samba-dev was listed for jessie 
(even though it was blocked from install) and is no longer available in 
testing or later...


$ apt-cache policy samba-dev
samba-dev:
  Installed: 2:4.4.5+dfsg-3
  Candidate: 2:4.4.5+dfsg-3
  Version table:
 *** 2:4.4.5+dfsg-3 1001
   1001 https://mirrors.ludost.net/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.2.10+dfsg-0+deb8u3 -1
 -1 https://mirrors.ludost.net/debian jessie/main amd64 Packages

Jessie used v4.2.10 of samba, and
Stretch is on v4.4.5 

In Samba 4.4, samba_util.h as well as several other public headers were 
removed.


You can see this information on the samba wiki: 
https://wiki.samba.org/index.php/Samba_4.4_Features_added/changed


I believe that apt-file is not very useful if it cannot tell you what 
release the file is for.


I'll give more detail on the senario:

1) Search for samba_util.h using apt-file
 $ apt-file search samba_util.h
   samba-dev: /usr/include/samba-4.0/samba_util.h

2) install the pacakge that was reported
$ sudo apt-get install samba-dev

3) Locate the header file
 $ ls /usr/include/samba-4.0/samba_util.h
   ls: cannot access '/usr/include/samba-4.0/samba_util.h': No such 
file or directory


-- um, what happened ?

Bug#840168: apt-file does not respect apt pinning priorities

2016-10-08 Thread William L. DeRieux IV 
Package: apt-file
Version: 3.1.1
Severity: important

apt-file does not respect apt pinning priorities and when a file
is found it's hard to determine (from the output) what release it is from.


$ cat /etc/apt/sources.list
deb [arch=amd64,i386] https://mirrors.ludost.net/debian/ jessie main contrib
non-free
deb [arch=amd64,i386] https://mirrors.ludost.net/debian/ stretch main contrib
non-free
deb [arch=amd64,i386] https://www.deb-multimedia.org stretch main non-free
deb [arch=amd64,i386] http://debug.mirrors.debian.org/debian-debug/ stretch-
debug main contrib non-free



$ cat /etc/apt/preferences
Package: *
Pin: release n=jessie
Pin-Priority: -1

Package: *
Pin: release n=stretch
Pin-Priority: 1000



$ sudo apt-file update
$ apt-file search samba_util.h
 samba-dev: /usr/include/samba-4.0/samba_util.h


In the above example apt-file is telling me that samba_util.h is included in
samba-dev, but this
was from the jessie distribution, and this file is not present in
testing/stretch or unstable.

Again, my apt preferences have jessie blocked from install and apt-file should
not report a file
being found in any package that cannot be installed -- without explicity
allowing it in apt/preferences.

At the very least apt-file could have a third column including the repository
url that the package is from.



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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 apt-file depends on:
ii  apt  1.3
ii  libapt-pkg-perl  0.1.29+b6
ii  liblist-moreutils-perl   0.416-1+b1
ii  libregexp-assemble-perl  0.36-1
pn  perl:any 

apt-file recommends no packages.

apt-file suggests no packages.

-- no debconf information

Bug#839594: /proc/iomem requires root privileges (changed in kernel 4.6)

2016-10-07 Thread William L. DeRieux IV 

#...quit
Using debian kernel 3.16.0-4-amd64 (3.16.36-1+deb8u1) -- /proc/iomem can 
be accessed without root.


Added in linux kernel 4.6: /proc/iomem: only expose physical resource 
addresses to privileged users


-
https://bugzilla.redhat.com/show_bug.cgi?id=1370281#c1
This was intentionally changed with

commit 51d7b120418e99d6b3bf8df9eb3cc31e8171dee4
Author: Linus Torvalds 
Date:   Thu Apr 14 12:05:37 2016 -0700

/proc/iomem: only expose physical resource addresses to privileged 
users


In commit c4004b02f8e5b ("x86: remove the kernel code/data/bss 
resources

from /proc/iomem") I was hoping to remove the phyiscal kernel address
data from /proc/iomem entirely, but that had to be reverted because 
some

system programs actually use it.

This limits all the detailed resource information to properly
credentialed users instead.

Signed-off-by: Linus Torvalds 

which was in the 4.6 kernel release.

Bug#839594: More concise write-up of the issue

2016-10-04 Thread William L. DeRieux IV 

--
In libsysinfo-0.2.2/Linux/sysinfo_linux.c fucntion get_mem_size(void):
--
long long get_mem_size(void) {

long long mem_size=0;

   /* First try any arch-specific memsize functions */
mem_size=get_arch_specific_mem_size();
if (mem_size == MEM_USE_MEMINFO) {
   mem_size = 0;
   goto use_meminfo;
}

if (mem_size == MEM_USE_SYSINFO) {
   mem_size = 0;
   goto use_sysinfo;
}

   /* Next try the 2.4.x+ method of iomem */
if (mem_size == 0) mem_size = get_mem_size_iomem();

   /* Try stat-ing /proc/kcore */
if (mem_size == 0) mem_size = get_mem_size_stat();

use_sysinfo:

   /* sysinfo should return same as /proc/meminfo */
   /* which, sadly, is often from 1MB-20MB off*/
if (mem_size == 0) mem_size = get_mem_size_sysinfo();

use_meminfo:
   /* If all else fails, try using /proc/meminfo */
if (mem_size == 0) mem_size = get_mem_size_meminfo();

return mem_size;
}
--
1) a call is made to get_arch_specific_mem_size()
 -- this will either return 0, MEM_USE_MEMINFO, or MEM_USE_SYSINFO.
 -- certain cpu_archs will return 0 (such as x86/x86_64)

2) if the return value is 0 it will call get_mem_size_iomem() [otherwise 
it will call get_mem_size_meminfo() or get_mem_size_sysinfo as appropriate]
 -- if not run as root the return value will always be 0 (or the system 
memsize, if run as root)


3) if the return value of iomem was 0 (and it will be, again without root)
   a call is made to get_mem_size_stat() reading from /proc/kcore -- 
currently this returns 128TB


   $ sudo file /proc/kcore
 /proc/kcore: ELF 64-bit LSB core file x86-64, version 1 (SYSV), 
SVR4-style, from 'BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-amd64 
root=UUID=8d8c2528-acc4-47a8-b815-967b59'


   $ sudo ls -lh /proc/kcore
 -r 1 root root 128T Oct  3 21:30 /proc/kcore

   Note that /proc/kcore cannot be relied upon because it is a mapping 
of the maximum amount of memory that the kernel can allocate and

   not how much ram is actually installed (at least not for 64-bit cpus)
--

The usefulness of these memory function(s):
1) get_mem_size_meminfo() and get_mem_size_sysinfo() -- are unreliable 
they will report less RAM than is actually installed
2) get_mem_size_stat() -- /proc/kcore unreliable on 64bit cpus (maybe 
even 32bit if less ram is installed than the 32bit max)
3) get_mem_size_iomem() -- fairly reliable in all cases, but requires 
root privs to read


--

The only reliable memory function is get_mem_size_iomem(), but -- in my 
opinion -- requiring linuxlogo to be executed as root is unnecessary and 
unacceptable.


As as result my recommendation would be to remove the feature altogether.

Bug#798080: mysql-server-5.6: service stop hangs forever on systemd -- fixed upstream

2016-10-02 Thread William L. DeRieux IV 

I had an older version installed and could confirm the issue existed;
but as of v5.6.30-1 this is no longer an issue.

Bug#839594: Update

2016-10-02 Thread William L. DeRieux IV 
I just realized that the problem is not necessarily with 
get_mem_size_iomem()
-- but the issue still requires root privileges to be able to read the 
system ram.

Bug#839594: linuxlogo requires root privs to read amount of system ram

2016-10-02 Thread William L. DeRieux IV 
Package: linuxlogo
Version: 5.11-8.1
Severity: normal
Tags: upstream

Dear Maintainer,

when linuxlogo (5.11-8.1) is executed as a normal user it reports that the
system has 128TB of ram; when it is run as root it will show the correct
amount.

The issue resides in file (ibsysinfo-0.2.2/Linux/sysinfo_linux.c)
In function get_mem_size_iomem is tries to read from /proc/iomem.
As a normal user all of the values will be -.

It should read the value for MemTotal from /proc/meminfo as this does not
require root privalges.

I don't think runing linuxlogo as root is neccessary or a good idea.



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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 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 linuxlogo depends on:
ii  libc6 2.24-3
ii  lsb-base  9.20160629

linuxlogo recommends no packages.

linuxlogo suggests no packages.

-- no debconf information

Bug#765069: Possible malware or viruses included as attachments in message 86 & 91

2016-09-01 Thread William L. DeRieux IV 

These two messages for bug #765069
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765069

Message 86: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765069#86
Message 91: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765069#91

File: PO645788.ace and air way bill.jar may possibly contain malware or
other malicious code (ie ransomeware) since PO645788.ace is a zip file 
containing an

obfuscated C# executable for windows.

I can only assume that 'air way bill.jar' is the same code only written
in java.

These messages should be removed as soon as possible to prevent users from
downloading infected

Bug#765069: vim-gnome: huge icon in application selection menu

2015-09-22 Thread William L. DeRieux IV 
Also forgot to mention that the back-ported patch was based on a patch 
for bug #744991 (attachment:297615)

and was backported to gtk+3.0-3.14.5 (in the file I attached)

Original patch: 
https://bug744991.bugzilla-attachments.gnome.org/attachment.cgi?id=297615



On 09/22/2015 08:31 PM, William L. DeRieux IV wrote:
The issue is confirmed to be in gtk+3.0-3.14.5 and was fixed in 
gtk+3.0-3.16


This issue is in gtk+3.0-3.14.5 and was patched in gtk+3.0-3.16
Related bug: Bug 744991 - Fix loading of GResource SVGs - 
https://bugzilla.gnome.org/show_bug.cgi?id=744991


git commit that fixed the issue: 
https://github.com/GNOME/gtk/commit/eddaf01676d3f6f28ca2609146be03a3dc9fd0b8

(icontheme: use desired size instead of negative for DIR_UNTHEMED SVGs)

This happens because unthemed svg icons were being given a negative 
width/height which caused them to be displayed without performing any 
scaling.


I am attaching the patch for gtk+3.0-3.14.5 (for jessie 8.2) -- that 
includes, only, the changes needed to fix the this issue.


bug #777615 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777615) 
should be merged into this issue as well.


Index: gtk-bugfix/gtk/gtkicontheme.c
===
--- gtk-bugfix.orig/gtk/gtkicontheme.c
+++ gtk-bugfix/gtk/gtkicontheme.c
@@ -3854,7 +3854,7 @@
 {
   gint size;
 
-  if (icon_info->forced_size)

+  if (icon_info->forced_size || icon_info->dir_type == 
ICON_THEME_DIR_UNTHEMED)
 size = scaled_desired_size;
   else
 size = icon_info->dir_size * dir_scale * icon_info->scale;
@@ -3884,7 +3884,7 @@
 {
   gint size;
 
-  if (icon_info->forced_size)

+  if (icon_info->forced_size || icon_info->dir_type == 
ICON_THEME_DIR_UNTHEMED)
 size = scaled_desired_size;
   else
 size = icon_info->dir_size * dir_scale * icon_info->scale;

Bug#777615: openshot: Huge application icon in Nautilus

2015-09-22 Thread William L. DeRieux IV 
On Tue, 10 Feb 2015 20:52:57 +0300 Dmitry Ostasevich 
 wrote:

> Package: openshot
> Version: 1.4.3-1.1
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
> huge icon is displayed for saved openshot projects in Nautilus.
> That is probably the same problem as in #765069 bug.
>
> -- System Information:
> Debian Release: 8.0
> APT prefers testing-updates
> APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: i386 (i686)
>
> Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages openshot depends on:
> ii fontconfig 2.11.0-6.3
> ii gtk2-engines-pixbuf 2.24.25-1
> ii librsvg2-common 2.40.5-1
> ii melt 0.9.2-2
> ii python 2.7.8-3
> ii python-gtk2 2.24.0-4
> ii python-httplib2 0.9+dfsg-2
> ii python-imaging 2.6.1-1
> ii python-mlt 0.9.2-2
> ii python-pygoocanvas 0.14.1-1+b3
> ii python-support 1.0.15
> ii python-xdg 0.25-4
>
> Versions of packages openshot recommends:
> ii frei0r-plugins 1.4-3
> ii openshot-doc 1.4.3-1.1
>
> Versions of packages openshot suggests:
> ii blender 2.72.b+dfsg0-3
> pn inkscape 
>
> -- no debconf information
>
>

Yes this is a duplicate of bug #765069.
I will be sending a rely on bug #765069 with a back-ported patch from 
gtk+ 3.16 that fixes the issue.


There is a work-around that can be used in the meantime (at least until 
the patch is accepted and back-ported).


1) Edit /usr/share/applications/openshot.desktop
2) change Icon=openshot -> Icon=/usr/share/pixmaps/openshot.svg

PS: without applying the back-ported patch
I would get huge icons for openshot in nemo (when browings files and on 
the desktop)  -- but did not have the issue in nautilus.
I might have something to due with the fact that I am using the 
cinnamon-desktop instead of the gnome desktop.

Bug#765069: vim-gnome: huge icon in application selection menu

2015-09-22 Thread William L. DeRieux IV 

The issue is confirmed to be in gtk+3.0-3.14.5 and was fixed in gtk+3.0-3.16

This issue is in gtk+3.0-3.14.5 and was patched in gtk+3.0-3.16
Related bug: Bug 744991 - Fix loading of GResource SVGs - 
https://bugzilla.gnome.org/show_bug.cgi?id=744991


git commit that fixed the issue: 
https://github.com/GNOME/gtk/commit/eddaf01676d3f6f28ca2609146be03a3dc9fd0b8

(icontheme: use desired size instead of negative for DIR_UNTHEMED SVGs)

This happens because unthemed svg icons were being given a negative 
width/height which caused them to be displayed without performing any 
scaling.


I am attaching the patch for gtk+3.0-3.14.5 (for jessie 8.2) -- that 
includes, only, the changes needed to fix the this issue.


bug #777615 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777615) 
should be merged into this issue as well.
Index: gtk-bugfix/gtk/gtkicontheme.c
===
--- gtk-bugfix.orig/gtk/gtkicontheme.c
+++ gtk-bugfix/gtk/gtkicontheme.c
@@ -3854,7 +3854,7 @@
 {
   gint size;
 
-  if (icon_info->forced_size)
+  if (icon_info->forced_size || icon_info->dir_type == ICON_THEME_DIR_UNTHEMED)
 size = scaled_desired_size;
   else
 size = icon_info->dir_size * dir_scale * icon_info->scale;
@@ -3884,7 +3884,7 @@
 {
   gint size;
 
-  if (icon_info->forced_size)
+  if (icon_info->forced_size || icon_info->dir_type == ICON_THEME_DIR_UNTHEMED)
 size = scaled_desired_size;
   else
 size = icon_info->dir_size * dir_scale * icon_info->scale;