Re: [Geeqie-devel] Project status

2016-03-10 Thread Hartmut Niemann
Hi Klaus!

If you are looking for a decent bug tracker and run your own server -
do you know redmine? It is an excellent rails-based bug tracker / 
project management
web system. I use it at work with subversion, but as far as I know it 
has a git
integration as well.

Hartmut



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-03-08 Thread Hartmut Niemann
Hi John!

You are certainly right that I can (and maybe should) run a
real 64bit kernel. I am already in the process of doing it,
but there are so many programs to install and configure
that it is going to take some time until my
64bit jessie can take over.

But I had the same problem with 4G of RAM.
So this is not a "more than 4GBytes of RAM is too much on a 32bit 
kernel" only problem.

I would like to understand why the system becomes unstable.
"Too much RAM" sounds too easy. There must be at least
one bug to find.

And I want to run all my tests on 64bit jessie as well.
I have not seen geeqie perform well under that condition yet.

Hartmut


Am 08.03.2016 um 22:26 schrieb John Stoffel:
> Klaus> Am Mo den  7. Mär 2016 um 23:12 schrieb Hartmut Niemann:
>>> $ cat /proc/version
>>> Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version
>>> 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17)
> I really think this is your problem in alot of ways.  You have an i686
> kernel (32bit) with the PAE extensions installed because you have 12gb
> of RAM in the system.  Why aren't you running a x86_64 (64bit) kernel
> and userland?  You can certainly install the 32bit libraries as well
> if you need them for an application.
>
> But moving to a pure 64bit kernel (can you send the output of cat
> /proc/cpuinfo?)  with a mixed 64bit/32bit userland (if needed) you'll
> get a much bigger address space.
>
> Now I can certainly see how geeqie, or possibly the toolkit and
> libraries, might not handle large amounts of highmem properly on a
> 32bit system using PAE.
>
> In my mind, it's just not worth the hassle.  How hard would it be to
> install a 64bit kernel on this system?
>
> John
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Geeqie-devel mailing list
> Geeqie-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geeqie-devel


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-03-08 Thread Hartmut Niemann

Hi!

John, you asked about versions:

$ cat /proc/version
Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc 
version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 
(2016-01-17)


$ geeqie --version
Geeqie 1.2

$ ldd `which geeqie`
linux-gate.so.1 (0xb77d5000)
libgtk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 
(0xb72b8000)
libgdk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0 
(0xb71f7000)
libpangocairo-1.0.so.0 => 
/usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0 (0xb71e8000)

libatk-1.0.so.0 => /usr/lib/i386-linux-gnu/libatk-1.0.so.0 (0xb71c)
libcairo.so.2 => /usr/lib/i386-linux-gnu/libcairo.so.2 (0xb7077000)
libgdk_pixbuf-2.0.so.0 => 
/usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0 (0xb704f000)

libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb6e99000)
libpangoft2-1.0.so.0 => 
/usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0 (0xb6e8)
libpango-1.0.so.0 => /usr/lib/i386-linux-gnu/libpango-1.0.so.0 
(0xb6e2e000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 
(0xb6dd)

libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb6ca8000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 
(0xb6c66000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 
(0xb6bb3000)
libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 
(0xb6bb)

libjpeg.so.62 => /usr/lib/i386-linux-gnu/libjpeg.so.62 (0xb6b51000)
libtiff.so.5 => /usr/lib/i386-linux-gnu/libtiff.so.5 (0xb6ad4000)
liblcms2.so.2 => /usr/lib/i386-linux-gnu/liblcms2.so.2 (0xb6a72000)
libexiv2.so.13 => /usr/lib/i386-linux-gnu/libexiv2.so.13 (0xb67e6000)
liblua5.1.so.0 => /usr/lib/i386-linux-gnu/liblua5.1.so.0 (0xb67b4000)
liblirc_client.so.0 => /usr/lib/liblirc_client.so.0 (0xb67ad000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb66bb000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb6675000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6657000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 
(0xb663b000)

libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb648e000)
libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 
(0xb6489000)

libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb6337000)
libXcomposite.so.1 => /usr/lib/i386-linux-gnu/libXcomposite.so.1 
(0xb6332000)

libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xb632e000)
libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xb6327000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb631b000)
libXinerama.so.1 => /usr/lib/i386-linux-gnu/libXinerama.so.1 
(0xb6317000)

libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xb6303000)
libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xb62f7000)
libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xb62eb000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb62d6000)
libpixman-1.so.0 => /usr/lib/i386-linux-gnu/libpixman-1.so.0 
(0xb621d000)

libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb61ef000)
libxcb-shm.so.0 => /usr/lib/i386-linux-gnu/libxcb-shm.so.0 (0xb61eb000)
libxcb-render.so.0 => /usr/lib/i386-linux-gnu/libxcb-render.so.0 
(0xb61e)

libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb61ba000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb619d000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb6193000)
libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb616b000)
libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 
(0xb6154000)
libharfbuzz.so.0 => /usr/lib/i386-linux-gnu/libharfbuzz.so.0 
(0xb60f7000)

libthai.so.0 => /usr/lib/i386-linux-gnu/libthai.so.0 (0xb60ed000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb60e4000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb6072000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb6049000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb602)
libjbig.so.0 => /usr/lib/i386-linux-gnu/libjbig.so.0 (0xb6011000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb600b000)
/lib/ld-linux.so.2 (0xb77d8000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb6007000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb6001000)
libgraphite2.so.3 => /usr/lib/i386-linux-gnu/libgraphite2.so.3 
(0xb5fda000)

libdatrie.so.1 => /usr/lib/i386-linux-gnu/libdatrie.so.1 (0xb5fd)

Unfortunately version 1.2.2 from testing and unstable has some dependencies
(Upgraded libraries) that I can't fulfill at the moment.


My normal workflow is that I mark some pictures as "1" and then "select 
all "1""

and "delete".
I observed that usually the problems start when I deleted a bunch of files.
I am not sure, but if I select "show only "1"" and then 

[Geeqie-devel] Resource leak in Geeqie 1.2 on debian jessie?

2016-02-25 Thread Hartmut Niemann
Hello!

My geeqie consumes HUGE amounts of main memory and every other day 
crashes the X server.

I mean: I flip through two or three directories of 100 photos each and I 
can watch
the (buffers?) memory rise in the GByte range.
After some usage, the thumbnail view starts having problems, showing 
about half of the thumbnails,
the rest is just white
(showing different thumbnails when I choose a different photo and the 
thumbnail view is redrawn).

When these problems start and I continue using it, sometimes it is 
aborted with some X error message
(next time I copy it to a file, I promise), sometimes X crashes and I am 
back to the login screen.

I use Debian Jessie on i86 (32bit). Since I upgraded from 4 GB to 12 GB 
of RAM, geeqie just takes even more of it :-(

I do not use Gnome, but LXDE, so it might be some (gnome-typical) tool 
or configuration detail missing.
Does anybody have an idea, what problem I have?

With best regards
Hartmut




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel