Problem with Socket Inter-Process Communication

According to Donald Welch it seems that there is a bug which is in the python-qt3 3.16 of Edgy but not in the older python-qt3 3.14. Donald suggests testing a downgrade to python-qt3 3.14 (see below). Can one simply install the Dapper package on Edgy?

I am also in favor of such a downgrade, as I have checked Mandriva 2007 (where faxing with HPLIP works) and they have still python-qt 3.14.

Is there any important requirement for python-qt3 3.16 in Edgy (important bug fix, compatibility with KDE 3.5.5, ...)? Or can we downgrade without problems in the final Edgy (for the case that faxing will work when testing with python-qt3 3.14).

Donald Welch wrote:

For a test, I'd like to downgrade python-qt3 from 3.16 back to 3.14. We have already had a defect against ver. 3.16 for something else previously, but I know that 3.14 works fine.

Any idea how I would do this?

please forward the report, no upstream bug tracker, ML at http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

downgrading doesn't seem to be an option, as python-kde3 depends on newer versions of python-qt3 (to install the dapper version, remove python-qt3 with --force-depends, download the python-qt3 and python2.4-qt packages from dapper and install them with dpkg -i)

Reported upstream:

http://mats.imk.fraunhofer.de/pipermail/pykde/2006-October/014444.html

Thanks Till. I worked on this for a few hours last night and I am fairly
confident there is a problem with QSocketNotifier in PyQt 3.16. PyQt
3.14works OK. I will be testing with
3.15 today.

Thanks,

Don

On 10/19/06, Till Kamppeter <email address hidden> wrote:
>
> Reported upstream:
>
> http://mats.imk.fraunhofer.de/pipermail/pykde/2006-October/014444.html
>
> --
> Problem with Socket Inter-Process Communication
> https://launchpad.net/bugs/66830
>

Thanks for the update, Don, I have posted it in the upstream thread now.

Till,

I did more testing. Here's my results:

x86 (32bit) Dapper 6.06 w/python-qt3 version 3.14 - Works
PPC Dapper 6.06 w/python-qt3 version 3.15 - Works
x86 (32bit) Edgy 6.10 (development branch) w/python-qt3 version 3.16 - Fails

Unfortunately, there is a bug in hpssd that I discovered while testing this
that makes it harder to test. I manually patched the version of hpssd on
each machine before each test.

I can supply a fixed version if needed.

Thanks,

Don

On 10/19/06, Till Kamppeter <email address hidden> wrote:
>
> Thanks for the update, Don, I have posted it in the upstream thread now.
>
> --
> Problem with Socket Inter-Process Communication
> https://launchpad.net/bugs/66830
>

Can you try 3.15 also on x86?

Does the bug fix for hpssd fix something user-visible? Can you post the fix?

Update from Donald Welch:

Update on testing:

x86 (32bit) Dapper 6.06 w/python-qt3 version 3.14 - Works
PPC Dapper 6.06 w/python-qt3 version 3.15 - Works
x86 ( 32bit) Edgy 6.10 (development branch) w/python-qt3 version 3.16 - Fails
x86 (32bit) Dapper 6.06 w/python-qt3 version 3.15 - Works

So, it appears that the problem was created moving from 3.15 to 3.16.

This would mean that a downdate to 3.15 would suffice. Is this possible without breakage?

Downgrading generally isn't possible, at least not without significant coordination to avoid future merge breakage (which adding an epoch would cause if not done very carefully indeed). Furthermore, as Matthias Klose said above, python-kde3 depends on the newer version of python-qt3. You could revert individual patches until it works, though ...

Jonathan, could you look into this?

I have also directly mailed to Phil Thompson (see below). According to him it is possible that the bug can be also in SIP.

SIP version in Ubuntu Edgy:

python-sip4 4.4.5-2ubuntu1 Python/C++ bindings generator runtime librar

SIP version in Mandriva 2007:

4.2.1 (see python/sip/ChangeLog in source tarball of kdebindings-3.5.4)

So it is also possible that recent changes in SIP broke it.

Phil's mail:
-----------------------------------------------------------

On Thursday 19 October 2006 8:30 pm, Till Kamppeter wrote:
> > Hi,
> >
> > due to a bug introduced with PyQt 3.16 the fax functionality of HPLIP
> > (http://hplip.sf.net/) does not work any more and so on distros shipping
> > this PyQt version (like Ubuntu Edgy) faxing with HP's multi-function
> > devices does not work in general.
> >
> > See
> >
> > http://mats.imk.fraunhofer.de/pipermail/pykde/2006-October/014444.html
> > http://mats.imk.fraunhofer.de/pipermail/pykde/2006-October/014447.html
> > http://mats.imk.fraunhofer.de/pipermail/pykde/2006-October/014449.html
> >
> > and also
> >
> > https://launchpad.net/distros/ubuntu/+source/python-qt3/+bug/66830
> >
> > As Ubuntu is about to be released next week, a quick and small patch
> > would be great. If it is a bigger issue I will try to get it into Edgy
> > as an official update.

It is unlikely to be a problem in QSocketNotifier itself as this hasn't
changed. You don't say what SIP versions you are using.

You need to produce an small, complete example that demonstrates the problem.

Phil

Does this affect hplip 1.6.9 in Edgy, or only the newer 1.6.10?

This problem I observed with all HPLIP 1.6.7, 1.6.9, and 1.6.10 on Edgy, so the currently shipping 1.6.9 has this problem, too.

Update from Donald Welch:

Till-

Just wanted to give you an update. So far my testing is, I think, inconclusive. Here's what I know:

1. The "stock" HPLIP install of 1.6.9/10 on Edgy doesn't work properly. I used Wireshark and confirmed that HPSSD is, in fact, sending data to the hp-toolbox client, but that the Qt message loop doesn't seem to "see" it (that is, the QSocketNotifier callbacks aren't fired). This was after extensively instrumented up the code. The easiest way to reproduce this test is as follows:

    1. Install and startup HPLIP 1.6.10
    2. Setup a printer (with hp:/ backend)
    3. Run the toolbox and switch to the installed printer's status tab
    4. Run the attached "event.py" that sends an asynchronous event to the toolbox via HPSSD. To do this, copy event.py to /usr/share/hplip and then run "python ./event.py -e 600"
    5. The toolbox should immediately show the status code "600" in the status tab (it will work on Dapper, but not on Edgy).

2. I created a client/server pair to test this in more isolation (attached server.py and client.py). Unfortunately, this pair of programs does work on both Edgy and Dapper. To run these:

    1. Run the server.py and not the port number it reports
    2. Run client.py with the port number as a command line parameter
    3. The client should show the time/date periodically in the window (it works in both Edgy and Dapper)

I am left feeling that this is less likely of a PyQt/SIP bug, but rather some subtle differences in usage and/or convention that have changed in Edgy or the PyQt/SIP code in Edgy. The stripped down client/server pair have of course removed and simplified a lot of code, which is where the problem could be. So, as a test, it is far from perfect or definitive.

I am open to any suggestions as to where to go with this next.

Regards,

Don

I can reproduce the hp-sendfax bug with the following configuration:

Kubuntu Edgy 6.10
python-qt3 3.16-1.2ubuntu1
hplip 1.6.9-0ubuntu2

Sending faxes with HP tools is not possible.

Regards,
Federico

Yes, this is the configuration that is known to not work.

It actually is still possible to send faxes, it requires the use of the "-n"
parameter:

$ hp-sendfax -n {...other params, see --help...}

-Don

On 11/20/06, Resnick <email address hidden> wrote:
>
> I can reproduce the hp-sendfax bug with the following configuration:
>
> Kubuntu Edgy 6.10
> python-qt3 3.16-1.2ubuntu1
> hplip 1.6.9-0ubuntu2
>
> Sending faxes with HP tools is not possible.
>
> Regards,
> Federico
>
> --
> Problem with Socket Inter-Process Communication
> https://launchpad.net/bugs/66830
>

Thanks Don,
it works fine using that flag.

For kdeprintfax users, do:
Settings -> Configuer kdeprintfax -> System
Fax System: "other"
Command: "hp-sendfax -pPRINTERNAME -f%number -n %files"

where PRINTERNAME is the name of the CUPS queue associated with your HP printer fax.

Hope that helped,
Federico

Thank you very much, faxing works very well this way and from KDE applications (which use kprinter as their printing dialog and kprinter uses kde printfax for faxing) it is even much easier than with the hp-sendfax GUI.

Is there a kdesendfax equivalent in GNOME/GTK, which is on the Ubuntu (without K) desktop CD?

We should put out an Errata message/release note, telling the user how to configure the fax GUIs of GNOME and KDE to send faxes with an hp-sendfax command line.

Naturally the PyQt bug needs to get fixed, too, but this way we have a workaround for the waiting users.

On the GNOME and XFCE Feisty CDs we should perhaps even pre-configure a GNOME/GTK fax frontend to use hp-sendfax, as they do not ship PyQt at all. This could be done by printerdrake (https://features.launchpad.net/distros/ubuntu/+spec/printerdrake).

I have installed HPLIP 1.7.1 from source on a Feisty test box and there fax works correctly. It seems that the HP guys have worked around or fixed the problem.

We put in place a polled solution that may or may not end up being
permanent. We are still pursuing a solution that works like the original
code (no polling).

On 1/25/07, Till Kamppeter <email address hidden> wrote:
>
> I have installed HPLIP 1.7.1 from source on a Feisty test box and there
> fax works correctly. It seems that the HP guys have worked around or
> fixed the problem.
>
>
> ** Also affects: hplip (upstream)
> Importance: Undecided
> Status: Unconfirmed
>
> ** Changed in: hplip (upstream)
> Status: Unconfirmed => Fix Released
>
> ** Also affects: hplip (Ubuntu)
> Importance: Undecided
> Status: Unconfirmed
>
> ** Changed in: hplip (Ubuntu)
> Importance: Undecided => Medium
> Status: Unconfirmed => Confirmed
>
> --
> Problem with Socket Inter-Process Communication
> https://launchpad.net/bugs/66830
>

New HPLIP packages (version 1.7.1 created

http://www.linux-foundation.org/~till/tmp/ubuntu/feisty/hplip/

Binaries for testing in the binary/ directory

Fax works with these ones.

Is this still a problem? It's been quite some time since there was activity on this bug.

I am going to close this report due to inactivity and no further issues reported concerning this issue. If you feel this is still an issue, then I urge you to reopen this report. Thank you!

This Printer is connected via a usb cable (Dont need wifi) All I require of it is the occasional scan and photocopy It has been nothing but trouble since I bought it. HP support is a Joke!!