Bug#972429: djview4: djview4 as a server

[Leon Bottou]

On Sun, 18 Oct 2020 21:10:41 +0100 "Barak A. Pearlmutter" 
 wrote:

> Good idea.
>
> There's a way to get some URLs sent to external programs, like magnet:
> links to transmission, or some files to evince. In Firefox it's
> Settings > General > Applications. Should be able to key off mime
> types I think, although I don't see djvu files there.
>
>


Yeah but you can add to that list from the ui. You have to write a 
mozilla or chrome extension which is an art that requires a lot of study 
(more than I have time for).  In addition it would be good to start 
djview with the URL before getting the data. This would allow djview to 
handle all the communication with the server, which is useful for 
indexed multipage documents.  Djview already does that : just pass a URL 
instead of a filename.


Alternatively you could even have djview decode the data and returns a 
bitmap for mozilla/chrome to display. Essentially this means using a 
small native server that decodes the data quickly, talking to this 
server with websockets, and implementing the djvu plugin UI in javascript.


But first one has to spend a couple months learning all this extension 
programming business and make it work across browsers...



- Leon

Bug#910449: libgtk3-nocsd0: There is no x32 version of the libgtk3-nocsd library

[Leon Bottou]

Package: libgtk3-nocsd0 

This causes a warning whenever a x32 binary is executed.

-- System Information: 

Bug#893771: Fwd: [djvu:bugs] #288 Clearing highlights no longer works

[Leon Bottou]

--- Begin Message ---
Fixed (commit d12583)

In fact the bug has been there forever, but did not show because qt4 was less 
strict than the qt5 xcb driver in interpreting update areas. Lots of little 
annotation display bugs have been corrected.


---

** [bugs:#288] Clearing highlights no longer works**

**Status:** open
**Group:** djview
**Created:** Fri Mar 23, 2018 09:05 AM UTC by Janusz
**Last Updated:** Fri Mar 23, 2018 09:05 AM UTC
**Owner:** nobody


I would like to draw your attention to my bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893771.
To say the truth, I don't use djview4 often, but the relevant code is used in
https://bitbucket.org/mrudolf/djview-poliqarp/
and there I will be missing the feature very much (I don't use djview4poliqarp 
systematically, but when I use it, then I use it very intensively developing 
indexes for a digitalized dictionary).
I would be very happy to help to diagnose the problem, unfortunately my skills 
are rather limited (I tried to use git bisec but got quite confused).
Best regards
Janusz


---

Sent from sourceforge.net because you indicated interest in 




To unsubscribe from further messages, please visit 
--- End Message ---

Bug#893771: Fwd: [djvu:bugs] #288 Clearing highlights no longer works

[Leon Bottou]

Upstream says: 
Fixed (commit d12583)
In fact the bug has been there forever, but did not show because qt4 was less 
strict than the qt5 xcb driver in interpreting update areas. Lots of little 
annotation display bugs have been corrected.


---

Bug#804888: Re: djview plugin unusable in debian testing...

[Leon Bottou]

On Tuesday, December 29, 2015 18:36:43 Leon Bottou wrote:
> >>So maybe the best thing would be to file a bug against qt5, fix things
> >>in this package by using qt4, and filing a wishlist bug against this
> >>package to use qt5, with a "blocked by" referring to the qt5 bug
> >>report above. That way when the qt5 issue is resolved the wishlist bug
> >>will be unblocked and notifications will flow...

Nevermind. After understanding sufficiently what is going on in the bowels of 
Qt, I implemented a workaround hack in a new release 4.10.5. This involves 
capturing the native xcb events and checking later whether Qt did the right 
thing.  This is ugly, but waiting for these guys could take forever...

I should do some real work now...

- L.

Bug#804888: Re: djview plugin unusable in debian testing...

[Leon Bottou]

On Tuesday, December 29, 2015 18:36:43 Leon Bottou wrote:
> >>So maybe the best thing would be to file a bug against qt5, fix things
> >>in this package by using qt4, and filing a wishlist bug against this
> >>package to use qt5, with a "blocked by" referring to the qt5 bug
> >>report above. That way when the qt5 issue is resolved the wishlist bug
> >>will be unblocked and notifications will flow...

Nevermind. After understanding sufficiently what is going on in the bowels of 
Qt, I implemented a workaround hack in a new release 4.10.5. This involves 
capturing the native xcb events and checking later whether Qt did the right 
thing.  This is ugly, but waiting for these guys could take forever...

I should do some real work now...

- L.

Bug#804888: Fixed in usptream release 4.10.5

[Leon Bottou]

Upstream release 4.10.5 contains a workaround for this qt bug.
- L.

Bug#809367: Re: Bug#809367: libqt5gui5: XEMBED interop with gtksocket broken

[Leon Bottou]

On Wednesday, December 30, 2015 10:13:52 Dmitry Shachnev wrote:
> Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-50212
> 
> Hi Leon,
> 
> On Tue, Dec 29, 2015 at 04:35:28PM -0500, Leon Bottou wrote:
> > This bug appears when one embeds a QWindow inside a GTK socket container
> > using the functions QWindow::setParent and QWindow::fromWinId().
> > According to the doc, the size of the QWindow should track the size of the 
> > container.
> > This used to work with Qt-5.2 and no longer works with this version of Qt.
> 
> I don't think I know anything about XEmbed, so let's wait for upstream to
> look at this issue. I have marked this bug as forwarded accordingly.
> 
> P.S. pygtk in the example? seriously? :)
> 
> --
> Dmitry Shachnev


XEmbed is the protocol that allows you to embed a window managed by one toolkit 
into a window managed by another toolkit, possibly running in another process. 
For instance this is the code that allows you to have a Qt system tray 
application inside a gnome desktop (or conversely).  This is also what allows 
us to run a Qt-based djvu viewer as a browser plugin inside mozilla (which is 
not Qt based.) 

Bug#804888: djview plugin unusable in debian testing...

[Leon Bottou]

Rethreading to l...@bottou.org






On 12/29/15, 6:28 PM, "Leon Bottou"  wrote:

>I've already reported a bug against qt5 for this  with a little test case.
>
><http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809367>
>
>And also a bug upstream referencing the debian bug...
>
>- L.
>
>
>
>
>
>On 12/29/15, 5:12 PM, "Barak A. Pearlmutter"  wrote:
>
>>So maybe the best thing would be to file a bug against qt5, fix things
>>in this package by using qt4, and filing a wishlist bug against this
>>package to use qt5, with a "blocked by" referring to the qt5 bug
>>report above. That way when the qt5 issue is resolved the wishlist bug
>>will be unblocked and notifications will flow...

Bug#804888: djview plugin unusable in debian testing...

[Leon Bottou]

I've already reported a bug against qt5 for this  with a little test case.



And also a bug upstream referencing the debian bug...

- L.





On 12/29/15, 5:12 PM, "Barak A. Pearlmutter"  wrote:

>So maybe the best thing would be to file a bug against qt5, fix things
>in this package by using qt4, and filing a wishlist bug against this
>package to use qt5, with a "blocked by" referring to the qt5 bug
>report above. That way when the qt5 issue is resolved the wishlist bug
>will be unblocked and notifications will flow...

Bug#809367:

[Leon Bottou]

Related bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804888

Bug#804888: djview plugin unusable in debian testing...

[Leon Bottou]

The upstream code for djview has been improved.
However the core of this problem is bug  
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809367 in Stretch's Qt-5.5.1.

Absent a Qt fix, we have two ugly workarounds:

  *   Compiling djview4 using Qt-4.8 instead of Qt-5.
  *   Have djview4 recognize the buggy versions of Qt-5 and use the supposedly 
obsolete Xt embedding protocol instead of XEMBED.


P.s. -- this is a djview4 issue.

- L.

Bug#809367:

[Leon Bottou]

Reported upstream: https://bugreports.qt.io/browse/QTBUG-50212

Bug#804888: djview plugin unusable in debian testing...

[Leon Bottou]

Not a simple one.
We would have to try embedding a window and observe the discrepancy 
between the size reported by xwininfo and the size reported by the qt program.
This seems very complex (and requires a X server..)

Happy new year, btw :-)

- L.




On 12/29/15, 4:48 PM, "Barak A. Pearlmutter"  wrote:

>Is there any reliable way to test for the buggy version of Qt-5?
>Because if there is we could do something in debian/rules or some
>place like that to fall back to Qt-4.8 iff Qt-5 is unavailable or
>buggy.

Bug#809367: libqt5gui5: XEMBED interop with gtksocket broken

[Leon Bottou]

Package: libqt5gui5
Version: 5.5.1+dfsg-10
Severity: normal

This bug appears when one embeds a QWindow inside a GTK socket container
using the functions QWindow::setParent and QWindow::fromWinId().
According to the doc, the size of the QWindow should track the size of the 
container.
This used to work with Qt-5.2 and no longer works with this version of Qt.

Here are the replication instructions:

* The following python program creates a window with a gtk socket
  and prints the window id of the socket

---
#!/usr/bin/env python

import gtk, sys, string

class Socket:
def __init__(self):
window = gtk.Window() 
window.set_default_size(200, 200) 
socket = gtk.Socket()
window.add(socket)
print(socket.get_id())
window.connect("destroy", lambda w: gtk.main_quit())
socket.connect("destroy", lambda w: gtk.main_quit())
socket.connect("plug-added", self.plugged_event)
socket.connect("plug-removed", self.unplugged_event)
window.show_all()

def plugged_event(self, widget):
print "A plug has been inserted."

def unplugged_event(self, widget):
print "A plug has been removed."
return True

Socket()
gtk.main()
---

* The following Qt program tries to embed itself
  into the container whose id is passed on the command line.

---
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
  QApplication app(argc,argv);
  long wid = app.arguments().at(1).toLong(0,0);
  QLabel *lbl = new QLabel();
  lbl->setText("here");
  lbl->setAlignment(Qt::AlignCenter);
  lbl->winId();
  QWindow *wlbl = lbl->windowHandle();
  wlbl->setParent(QWindow::fromWinId(wid));
  lbl->show();
  app.exec();
}
---

* To reproduce, open a terminal window, run "gtksocket.py"
  and record the printed socket window id. This creates
  a toplevel window containing the socket. In a second terminal window,
  run "plug ".
  The label text "here" appears in socket window.

* Under Qt-5.2, the label text appears in the middle of
  the window because the QLabel widget has the same size
  as the gtksocket window.  Resizing the gtksocket window
  keeps the text "here" in the middle of the window because
  the QLabel widget size tracks that of the socker.

* Under Qt-5.5.1+dfsg-10, the label text appears in the top left
  corner of the window and stays there. Using program "xwininfo"
  shows that the size of the underlying X11 window effectively
  tracks the size of the gtksocket. But it appears that
  the size of the QWindow and of the associated QLabel
  remains stuck to its initial value.


As a consequence, XEMBED interop is broken in this version of Qt.




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

Kernel: Linux 4.3.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
Init: systemd (via /run/systemd/system)

Versions of packages libqt5gui5 depends on:
ii  fontconfig   2.11.0-6.3
ii  libc62.21-4
ii  libegl1-mesa [libegl1-x11]   11.0.8-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.1-0.1
ii  libgl1-mesa-glx [libgl1] 11.0.8-1
ii  libglib2.0-0 2.46.2-1
ii  libharfbuzz0b1.0.1-1+b1
ii  libinput10   1.1.3-1
ii  libjpeg62-turbo  1:1.4.1-2
ii  libmtdev11.1.5-1
ii  libpng12-0   1.2.54-1
ii  libqt5core5a [qtbase-abi-5-5-1]  5.5.1+dfsg-10
ii  libqt5dbus5  5.5.1+dfsg-10
ii  libqt5network5   5.5.1+dfsg-10
ii  libstdc++6   5.3.1-4
ii  libudev1 228-2+b1
ii  libx11-6 2:1.6.3-1
ii  libxkbcommon00.5.0-1
ii  libxrender1  1:0.9.9-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages libqt5gui5 recommends:
ii  libqt5svg5 5.5.1-2
ii  libqt5xcbqpa5  5.5.1+dfsg-10

Versions of packages libqt5gui5 suggests:
pn  libqt5libqgtk2 
pn  qt5-image-formats-plugins  
pn  qtwayland5 

-- no debconf information

Bug#714225: djview4 menu bar cycle

[Leon Bottou]

On Friday, June 28, 2013 10:46:50 AM Barak A. Pearlmutter wrote:
> djview4 menu bar cycle issue, http://bugs.debian.org/714225


This is hard to reproduce without having exactly the same screen.

Dylan wrote "shouldn't "fit page" never have menu bars?".
This makes me think that this is more about the scrollbars.

(see also: https://sourceforge.net/p/djvu/bugs/211/)

However there should be no scrollbars in fullscreen mode. By default there 
should be just a toolbar that can be switched on or off with key F10.
This could be changed by tweaking the "interface" preferences in a complicated 
way (uncheck the "remember" box and manually switch the menubar or the 
scrollbars on or off). But even in this case, I would like things to work 
correctly. But I need to know if this is the case...

Can you clarify?

Just to agree on the terminology: 
- menubar (File, Edit, etc.)
- toolbar (with little icons)
- vertical and horizontal scrollbars
- status bar
- docked widgets (outline, thumbnails, and find)

Note that I just made subtle changes in the git repository
to improve the prevention of scrollbar loops. However I am not 
sure that this is related to the problem Dylan describes.

- L.



- L.

Bug#714225: djview4 menu bar cycle

[Leon Bottou]

On Friday, June 28, 2013 10:46:50 AM Barak A. Pearlmutter wrote:
> djview4 menu bar cycle issue, http://bugs.debian.org/714225


This is hard to reproduce without having exactly the same screen.

Dylan wrote "shouldn't "fit page" never have menu bars?".
This makes me think that this is more about the scrollbars.

(see also: https://sourceforge.net/p/djvu/bugs/211/)

However there should be no scrollbars in fullscreen mode. By default there 
should be just a toolbar that can be switched on or off with key F10.
This could be changed by tweaking the "interface" preferences in a complicated 
way (uncheck the "remember" box and manually switch the menubar or the 
scrollbars on or off). But even in this case, I would like things to work 
correctly. But I need to know if this is the case...

Can you clarify?

Just to agree on the terminology: 
- menubar (File, Edit, etc.)
- toolbar (with little icons)
- vertical and horizontal scrollbars
- status bar
- docked widgets (outline, thumbnails, and find)

Note that I just made subtle changes in the git repository
to improve the prevention of scrollbar loops. However I am not 
sure that this is related to the problem Dylan describes.

- L.



- L.

Bug#628800: FTBFS on kfreebsd-*: libdjvulibre.so: undefined reference to symbol 'pthread_cancel@@GLIBC_2.3'

[Leon Bottou]

 
Done.

Note that the source of the problem is in libtool.
On Linux (and apparently on debian/kbsd), libtool links libraries 
with -nostdlib and therefore prevents gcc to include -lpthread 
automatically when given option -pthread.

- L.





On Wednesday, June 01, 2011 04:54 pm, Leon Bottou wrote:
> I believe Michael is right and I'll change that tonight.
> - L.
> 
> 
> 
> > -Original Message-
> > From: Barak A. Pearlmutter [mailto:ba...@cs.nuim.ie]
> > Sent: Wednesday, June 01, 2011 4:45 PM
> > To: Michael Biebl
> > Cc: 628...@bugs.debian.org; debian-...@lists.debian.org; Leon Bottou
> > Subject: Re: Bug#628800: FTBFS on kfreebsd-*: libdjvulibre.so: undefined
> > reference to symbol 'pthread_cancel@@GLIBC_2.3'
> > 
> > > I just wanted to mention, that there is a difference between
> > >
> > > *kfreebsd*-yes (my proposed patch)
> > > and
> > > *freebsd*-yes (what was merged upstream [1])
> > >
> > > afaik the freebsds don't use the glibc userland and I'm not sure if
> > > the thread libs on freebsd behave like the one on kfreebsd, so I just
> > > wanted to verify that what you merged upstream is intentional and the
> > > missing 'k' is not an oversight.
> > 
> > I'm not sure: upstream did that patch independently of yours, and I saw it
> > looked about the same and blindly merged it.
> > 
> > I'm CCing this message to upstream to let it be addressed directly.
> > 
> > But I will close with a parenthetical grouse: isn't this exactly the sort
> of tedious
> > system-by-system manual non-future-proof groveling that autotools is
> > supposed to abolish?  Could this be tested automatically using existing
> > autoconf macros?
> > 
> > --Barak.
> 

Bug#628800: FTBFS on kfreebsd-*: libdjvulibre.so: undefined reference to symbol 'pthread_cancel@@GLIBC_2.3'

[Leon Bottou]

I believe Michael is right and I'll change that tonight.
- L.



> -Original Message-
> From: Barak A. Pearlmutter [mailto:ba...@cs.nuim.ie]
> Sent: Wednesday, June 01, 2011 4:45 PM
> To: Michael Biebl
> Cc: 628...@bugs.debian.org; debian-...@lists.debian.org; Leon Bottou
> Subject: Re: Bug#628800: FTBFS on kfreebsd-*: libdjvulibre.so: undefined
> reference to symbol 'pthread_cancel@@GLIBC_2.3'
> 
> > I just wanted to mention, that there is a difference between
> >
> > *kfreebsd*-yes (my proposed patch)
> > and
> > *freebsd*-yes (what was merged upstream [1])
> >
> > afaik the freebsds don't use the glibc userland and I'm not sure if
> > the thread libs on freebsd behave like the one on kfreebsd, so I just
> > wanted to verify that what you merged upstream is intentional and the
> > missing 'k' is not an oversight.
> 
> I'm not sure: upstream did that patch independently of yours, and I saw it
> looked about the same and blindly merged it.
> 
> I'm CCing this message to upstream to let it be addressed directly.
> 
> But I will close with a parenthetical grouse: isn't this exactly the sort
of tedious
> system-by-system manual non-future-proof groveling that autotools is
> supposed to abolish?  Could this be tested automatically using existing
> autoconf macros?
> 
>   --Barak.




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

Bug#582961: Fixed upstream

[Leon Bottou]

This bug has just been fixed upstream (cvs).

The change ensures that, regardless of what other threads do,
condition locker==self implies that the current thread owns the lock.
In the past, we used to rely on another thread writing into this
variable. Problems then arise when variables count and locker are
not synchronized together, for instance when they belong to
different cache lines.  Hairy!

- L.


===
--- GThreads.cpp30 Aug 2010 03:14:07 -  1.21
+++ GThreads.cpp30 Aug 2010 05:10:15 -  1.22
@@ -808,6 +808,7 @@
 void
 GMonitor::leave()
 {
+  static pthread_t pthread_null;
   pthread_t self = pthread_self();
   if (ok && (count>0 || !pthread_equal(locker, self)))
 G_THROW( ERR_MSG("GThreads.not_acq_broad") );
@@ -815,6 +816,7 @@
   if (count > 0)
 {
   count = 1;
+  locker = pthread_null;
   if (ok)
 pthread_mutex_unlock(&mutex);
 }








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

Bug#564684: djvulibre-bin: djvused output-* does not escape fileids

[Leon Bottou]

Fixed in upstream CVS.



On Monday 11 January 2010 05:51:26 Jakub Wilk wrote:
> Package: djvulibre-bin
> Version: 3.5.22-7
> Severity: normal
> 
> output-* commands of djvused do not properly escape ' and \ characters 
> in file identifiers, thus they can output broken scripts:
> 
> $ djvused -e output-txt dummy.djvu 
> select; remove-txt
> # -
> select 'dummy.djvu'
> set-txt
> (page 0 0 1 1 "dummy")
> 
> .
> 
> $ djvused -e output-txt dummy.djvu | djvused -f - dummy.djvu 
> djvused: (warning) file was modified but not saved
> 
> $ ln dummy.djvu "weird'o.djvu"
> 
> $ djvused -e output-txt weird*.djvu | djvused -f - wierd*.djvu
> *** page "weird" not found
> *** (djvused.cpp:346)
> *** 'void verror(const char*, ...)'
> 
> 
> 
> -- System Information:
> Debian Release: squeeze/sid
>APT prefers unstable
>APT policy: (900, 'unstable'), (500, 'experimental')
> Architecture: i386 (i686)
> 
> Kernel: Linux 2.6.31-1-686 (SMP w/2 CPU cores)
> Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages djvulibre-bin depends on:
> ii  curl  7.19.7-1   Get a file from an HTTP, HTTPS 
> or 
> ii  libc6 2.10.2-4   Embedded GNU C Library: Shared 
> lib
> ii  libdjvulibre213.5.22-7   Runtime support for the DjVu 
> image
> ii  libgcc1   1:4.4.2-9  GCC support library
> ii  libstdc++64.4.2-9The GNU Standard C++ Library v3
> ii  libtiff4  3.9.2-1Tag Image File Format (TIFF) 
> libra
> 





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

Bug#504340: djvulibre-plugin/testing and #504340

[Leon Bottou]

On Monday 29 December 2008 18:39:17 Thomas Viehmann wrote:
> Hi,
> So here is something even better (IMHO): Change map_lookup to return the
> return value (note that this would be funny if we stored NULLs in the

Ok. I am doing that upstream.
This is the best way to avoid the pitfalls of the ANSI C strict aliasing rules.
These stupid rules basically prevent us from accessing 
an arbitrary pointer using a void* type. 
I wonder why they did not handle the case of void* pointers
in the rules. I did not find any explanation online...

- L.



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

Bug#504340: Why -O3

[Leon Bottou]

On Sunday 28 December 2008 19:27:16 Bastien ROUCARIES wrote:
> I think inconditionnally switch to -O2 is the best. i will close the bug for 
> lenny :-) 
> Create smaller binary and often better (less icache),  
> and will let investigate this bug that could be a gcc bug 
> What do you think?

Quite a while ago, using -O3 gave much better results 
on the tight integer loops of the wavelet decoder (in libdjvu only).
I suggest to check if the patch I sent yesterday works
and decide on that basis.

- L.

P.S. --

On the other hand, should we really assume that 
gcc is too flaky to be used with -O3?

In fact I am not even sure that gcc is flaky.
I think the problem is with the c aliasing rules.
Basically they say that writing through a T* pointer
cannot change a variable of type other than T,
except when T is "char". If using -O3 triggers that,
we can expect -O2 to do the same in the future.

I believe a similar exception should be done 
when T is "void" as it is common to use void* 
pointers as universal pointers (this
is in fact encouraged by the casting rules.)
From past experience, I have renounced asking 
the gcc people to implement that, since this
is not in the standard. Yet it would eliminate 
lots of hard-to-debug bugs.



 



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

Bug#504340: [djvulibre-plugin] And not fixed upstream

[Leon Bottou]

On Saturday 27 December 2008 14:11:43 Bastien ROUCARIES wrote:
> Not fixed upstream BTW
> "ROUCARIÈS Bastien"

I just made a little change to help the compiler 
perform aliasing analysis around map_lookup.
Using char* instead of void* often helps
because the C aliasing rules are crazy.

Please let me know if the cvs version of djvulibre-3.5 now works.
Otherwise we'll have to hack the makefiles to use -O2.

- L.




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

Bug#377468: Plugin architecture & library conflicts

[Leon Bottou]

On Saturday 27 December 2008 22:23:13 Michel Briand wrote:
> The plugin could be a split between a very simple wrapper and a
> distinct application. The plugin would swallow the X window of
> the "real" plugin : the separate application. That's the design of
> FreeWRL's plugin and it works. Even with this design we can receive X
> events from the browser (passthrough).

The djview plugin already works this way.
However it is still necessary to capture a few events to
properly handle the swallowing (window resizing, 
keyboard events propagation, window destruction).
Things may be less fragile with the Xembed plugin option,
but that does not work with all browsers...

- L.






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

Bug#377468: (no subject)

[Leon Bottou]

Let me explain my reasonning as the upstream developper.


The plugin api implicitely mandates that one uses
some basic Xt calls to capture gui events from 
the browser event loop. With some browsers, one can also 
set a flag to use the xembed protocol: it is then 
recommended to capture events using glib calls.

In both cases, these are very basic calls
that are unlikely to be ever removed or changed
from either Xt or GLib. Too many programs depend on them.

However it is most important that these calls
affect the data structures of the browser event loop.
In other words, one should be *certain* to use
the same Xt or GLib version as the browser itself.
Using a different version of libX11
would not be nearly as bad...

In my experience, the danger of linking with a different version of Xt
is greater than the danger of seeing a change in a few Xt functions
that haven't changed in the last 20 years...

This reasonning makes sense for the upstream distribution.

In Debian, if you can be certain that all Debian browsers use the same Xt
version, you can link with that one. Then change is quite trivial
since 'configure.ac' contains code to explicitely remove -lXt and -lXext.  
I think this is slightly unwise, but without hard feelings.

I also would like to point out that the current djvulibre plugin code,
unmodified, produces binaries that have been shown to work with a large 
number of browsers including the original netscape, gecko based browsers, 
khtml based browsers and some versions of opera.  I believe I have
solid experience in that aspect of plugin programming...

Happy new year to all of you 
and thanks for the precious help...

- L.




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

Bug#504340: djvulibre-plugin/testing and #504340

[Leon Bottou]

Let me chime in as the main upstream developper.

Thomas thinks that plugin code can be called from multiple thread
and proposes a patch for locking critical data structures.
If this assumption is correct, Thomas patch seems perfectly sane
On the other hand, I will not include and maintain such additional 
complexity upstream without evidence that the assumption is correct.

I understand that debian deadlines can suggest to do differently.
The debian maintainers have the last say about that.

I wrote a little code to check whether Thomas assumption is correct.
Under firefox3 on ubuntu (my laptop), the plugin is always called
from the same thread.  There is no crash.

It is possible that iceweasel does things differently.
I'd be glad if someone can test it using the code attached with my
previous post.  If iceweasel calls plugins from multiple threads,
it makes sense to include such a patch. It also makes
sense to wonder whether more plugin issues would be solved
by having iceweasel make all plugins calls from the same thread
(something firefox apparently does).  I would then add upstream
a locking code with provisions to enable or disable it
from the configure script (djvulibre has to work on lots of platforms.)

If iceweasel does not call plugins from multiple threads,
Thomas patch cannot solve the bug since it addresses a 
non existent condition.  I do not think then that the patch
should be included upstream. 

Another related bug also describes a djvulibre plugin crash
from the kde plugin component nspluginviewer. 
This component is not multithreaded.  Regardless
of the conclusion of the iceweasel multithreading test,
something is going on there as well.

Finally I would also try to reduce the plugin optimization 
level from -O3 to -O2, just to see if improvements appear.
This is another difference between Bastien's experiments 
(no crash, plugin compiled from djview4 source with -O2) and 
the distribution (crash, plugin compiled from djvulibre 
source with -O3)...

In short, my upstream decision will depend on
the result of additional investigation.
Again, I understand that the debian schedule may
incite the debian maintainers to decide otherwise...

Happy new year for all of you.
and warm thanks for the precious help.

- Leon Bottou






On Tuesday 23 December 2008 17:01:50 Thomas Viehmann wrote:
> Hi,
> 
> so Luk wanted to give people a chance to comment before deciding on this
> largish fix. I have since privately received correspondence from Leon
> indicating that at first sight, the patch looked sane but is doing too
> much at once, but would not have time for a more thorough analysis
> before the second week of next year.
> I would really like to see a working djvulibre-plugin in lenny, so I
> wonder what the plan should be. Please also add other djvulibre bugs to
> fix in a t-p-u upload if you so desire.
> 
> Kind regards
> 
> T.
> -- 
> Thomas Viehmann, http://thomas.viehmann.net/
> 
> 
> 





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

Bug#500919: (no subject)

[Leon Bottou]

Without a test document, I cannot be sure.
However I strongly suspect that this is the same issue as
http://sourceforge.net/tracker/index.php?func=detail&aid=1997033&group_id=32953&atid=406583

In other words, the pdf link handling in gs is insufficient.
Gsdjvu (which is not a debian package) is based on the pristine ghostscript.
Nothing will happen until somebody fixes gs, and until we build a new
gsdjvu on the basis of the fixed ghostscript.

As mentionned by ubanus in the sourceforge bug report,
it is possible to combine gsdjvu graphics accuracy
with pdf2djvu better handling of pdf files.
Of course this is a tweak..

Eventually the solution would be to port or recode the better 
gsdjvu rendering into pdf2djvu. This could happen if AT&T agrees 
to adjust the gsdjvu license, or if the patent expires...


- L.






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

Bug#504340: djvulibre-plugin/testing and #504340

[Leon Bottou]

On Thursday 18 December 2008 18:16:54 Thomas Viehmann wrote:
> Thomas Viehmann
>
>   if (map_lookup(&instance, id, &inst) < 0)
> return NPERR_INVALID_INSTANCE_ERROR;
>-  cur_window = inst->window;
>+  cur_window = (inst) ? inst->window : 0;

The problem here is that inst should not be zero if map_lookup returns 
correctly.
Like the previous patch, a seemingly unrelated change seems to solve the 
problem.
The bug appears or disappears depending on the compiler options
or depending on the insertion of printf in the right places.
Your patch cannot hurt, but I do not think it is the end of the story either...

- L.



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

Bug#504340: Seems a hinsenbug

[Leon Bottou]

On Wednesday 10 December 2008 11:34:51 Bastien ROUCARIES wrote:
> Le lundi 8 décembre 2008, Leon Bottou a écrit :
> > On Sun, December 7, 2008 4:37 pm, Bastien ROUCARIES wrote:
> > > Strange it is an hinsenbug, turning on debugging and the bug desapear :-(
> > 
> > If you turned on debugging using the latest cvs,
> > be aware I performed a blind change on the basis of the earlier bug reports.
> > But does the bug reappear if you turn off debugging?
> 
> No it does not reappear, seems you fixed the bug :-)
> Could you send a changelog?


Changelog: no longer assume the browser passes the correct information
in the NPSetWindowCallbackStruct in NPP_SetWindow.


   if (new_window)
 {
-  NPSetWindowCallbackStruct *cbs
-= (NPSetWindowCallbackStruct *) win_str->ws_info;
-  Display * displ=cbs->display;
+  Display *displ = 0;
+  if (NPN_GetValue(np_inst, NPNVxDisplay, &displ) != NPERR_NO_ERROR)
+displ = ((NPSetWindowCallbackStruct *)(win_str->ws_info))->display;
   if (!IsConnectionOK(FALSE))
 return NPERR_GENERIC_ERROR;
---



I am not convinced this was the whole story.
Does it work in konqueror as well?

- L.



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

Bug#504340: Seems a hinsenbug

[Leon Bottou]

On Sun, December 7, 2008 4:37 pm, Bastien ROUCARIES wrote:
> Strange it is an hinsenbug, turning on debugging and the bug desapear :-(

If you turned on debugging using the latest cvs,
be aware I performed a blind change on the basis of the earlier bug reports.
But does the bug reappear if you turn off debugging?
- L.






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

Bug#504340: Strange...

[Leon Bottou]

Djvulibre upstream here:

This bug is bizarre because:
- the iceweasel crash in NPP_SetWindow suggests 
  that the cause is somewhere in nsdejavu.so
- crashes occur also with kde's nspluginviewer.
- nsdejavu.so is a very thin wrapper; its source
  has not changed in ages, and works fine in other
  setups such as firefox3 in ubuntu.

Somehow I suspect something subtle changed in the binary interface.
But I am not sure because I was not able to determine if nspluginviewer
uses the nsplugin sdk files from iceweasel or those included in kde.

I won't be able to have a lenny install running before mid-january.
However I made small changes in the copy of nsdejavu that comes with djview4.
I'd be happy to see what they give (compiled with -g for more information).

Procedure to test it:
$ apt-get install libqt4-dev 
$ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/djvu co -P djview
$ cd djview
$ configure --prefix=/usr --enable-debug
$ make
$ cd nsdejavu
$ sudo cp .libs/nsdejavu.so /usr/lib/netscape/plugins-libc6/nsdejavu.so

Thanks to anyone who can give me a little more information.

- Leon Bottou



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

Bug#484522: Fixed upstream in CVS

[Leon Bottou]

But has been fixed upstream in CVS.
- L.



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

Bug#468389: Cannot replicate with current upstream cvs

[Leon Bottou]

Cannot replicate with current upstream cvs.
Work here...
- L.



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

Bug#460714: Fixed in cvs upstream

[Leon Bottou]

Bug has been fixed in upstream CVS.
- L.



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

Bug#446774: ivtools: Comdraw crashes when entering a comdraw command.

[Leon Bottou]

Package: ivtools
Version: 1.1.3-5.3
Severity: important
Tags: patch


Steps to reproduce on an amd64 machine.

1) start comdraw
2) type 'help' in the ComEditor pane, followed by key .
3) observe the crash.

Patch:

--- ivtools-1.1.3.orig/src/ComTerp/comterp.c
+++ ivtools-1.1.3/src/ComTerp/comterp.c
@@ -165,7 +166,9 @@
 &_pfbuf, &_pfsiz, &_pfnum);

 _pfoff = 0;
-return status==0 && _pfbuf[_pfnum-1].type != TOK_EOF && _buffer[0] != '\0';
+return status==0
+  && (_pfnum==0 || _pfbuf[_pfnum-1].type != TOK_EOF)
+  && _buffer[0] != '\0';
 }

 boolean ComTerp::eof() {



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



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

Bug#444214: konqueror-nsplugins: nspluginviewer crashes on amd64 (with explanation of the cause)

[Leon Bottou]

Package: konqueror-nsplugins
Version: 4:3.5.5a.dfsg.1-6etch1
Severity: grave
Justification: renders package unusable


Nspluginviewer crashes immediately on AMD64 
without displaying anything.

Version 4:3.5.5a.dfsg.1-6etch1 of konqueror-nsplugins
was apparently compiled using an ancient version
of the netscape sdk that declares uint32 as long
on all platforms except the alpha.
This is obviously wrong on amd64.

Related upstream bug:
http://bugs.kde.org/show_bug.cgi?id=150241

Fix:
 Line 190 of npapi.h should be
  #if defined(__alpha) || defined(__x86_64__) || defined(__LP64__)
 instead of
  #if defined(__alpha) 

That's all.

- Leon Bottou



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages konqueror-nsplugins depends on:
ii  kdelibs4c2a4:3.5.5a.dfsg.1-8 core libraries and binaries for al
ii  libc6  2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii  libgcc11:4.1.1-21GCC support library
ii  libqt3-mt  3:3.3.7-4 Qt GUI Library (Threaded runtime v
ii  libstdc++6 4.1.1-21  The GNU Standard C++ Library v3
ii  libx11-6   2:1.0.3-7 X11 client-side library
ii  libxt6 1:1.0.2-2 X11 toolkit intrinsics library

konqueror-nsplugins recommends no packages.

-- no debconf information



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

Bug#435723: Correct my previous email

[Leon Bottou]

My mistake.
This libc was not the stable one.
I do not know how I got it,
but it is not debian stable.
- L.


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

Bug#435723: printf with %g causes a segmentation violation.

[Leon Bottou]

On Friday 03 August 2007 08:34:15 you wrote:
> On Thu, Aug 02, 2007 at 04:44:06PM -0400, Leon Bottou wrote:
> > Version: 2.5-3
> > 
> > $ gcc l.c
> > $ ./a.out
> > 0.000100
> > 1.00e-04
> > Segmentation fault
> > $
> I can't reproduce this with 2.6-2.
Good news.

I use a debian etch (stable) on x86_64
kept up to date with apt-get upgrade.
Basically this happens with the binary libc
currently distributed on the debian servers, as of 2007-08-03.  
I do not know which compiler has been used to compile them.

This segfault is a little bit freaky.
The value 9.9991e-05 is important.
If you take 10e-5, no segfault.
A debug trace suggests that printf calls wmemset 
with incorrect arguments. I'll try to learn more.

- L.







This is what we get with debian etch.


> 




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

Bug#435723: printf with %g causes a segmentation violation.

[Leon Bottou]

Package: glibc
Version: 2.5-3

Debian version: etch
Platform: x86_64
GCC version: 4.1.1-15.

The following program causes a segmentation violation:

$ cat > l.c
#include 
int main()
{
  double d = 9.9991e-05;
  printf("%f\n", d);
  printf("%e\n", d);
  printf("%g\n", d);
}


$ gcc l.c
$ ./a.out
0.000100
1.00e-04
Segmentation fault
$

That was unexpected :-).

- L.



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

Bug#418618: Workaround

[Leon Bottou]

I determined that this is a file parsing problem.
Specifying and explicit broadcast address instead of @LOCAL works.
 BrowseRelay 127.0.0.1  192.168.1.255  

- L.


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

Bug#418618: BrowseRelay does not work with BrowsePoll.

[Leon Bottou]

Package: cupsys
Version: 1.2.7-4

The cups documentation says that BrowseRelay
can relay printers found using BrowsePoll.
| BrowseRelay is typically used on systems that bridge multiple
| subnets using one or more network interfaces. It can also be used
| to relay printer information from polled servers with the line:  
|   BrowseRelay 127.0.0.1 @LOCAL
| This effectively provides access to printers on a WAN for all clients on the 
LAN(s).
See also http://www.easysw.com/printpro/howto.php?19#19

That does not work with 1.2.7-4.
Polled printers are not broadcast on the local network.
I checked with ethereal that no udp packets are sent from port 631.
Since my config has no other printers, I also
tried to create a local printer on the cups server.
That local printer gets advertised as expected, 
but the printers from the polled servers are not.





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