-Don
On 10/30/06, Henrique de Moraes Holschuh <
[EMAIL PROTECTED]> wrote:
Yes, you are correct. It was partly your input into these issues that moved me to change it to how it is done today.
I think I/we can get the PyQt people to respond, _if_ I could manage a simple example (haven't yet).
The reason that PyQt is involved with IPC at all is that I have to be able to respond to I/O on the IPC socket in the PyQt/Qt message loop. PyQt doesn't provide any other services beyond providing a callback when data is ready to read on the IPC socket.
We've never seen this behavior (at least in the last year). Is there any way you could show us how to duplicate it or test it?
Thanks,
Don
On Mon, 30 Oct 2006, Till Kamppeter wrote:
> Every user has a hot folder named ~/hpfax/ in his home directory
> (auto-created if needed).
>
> When a user sends a job into the fax queue, the hpijs driver converts
> the job into fax G3 format and the hpfax CUPS backend drops the fax G3
> file in the user's hot folder (hot folder created by hpfax backend if
> needed). hpfax should be fairly the same code as the cups-pdf backend
> available as free software here (and available as Debian package in
> Ubuntu Edgy):
This is essentially impossible to get right re. security, it will clash
terribly with SELinux, and it will cause all manners of problems. It is
also how fax was implemented in HPLIP in the 0.9 days, I think.
Yes, you are correct. It was partly your input into these issues that moved me to change it to how it is done today.
I am opposed to doing things this way, even if I am one of the affected
parties both personally (my MFT doesn't fax because of the bug and I am a
eat-your-dogfood type of person, so it will NOT fax until all Debian users
can also fax too) and as a distribution maintainer (Debian Etch and Sid are
affected by the PyQT bug just as much as Ubuntu).
So what PyQT is buggy? We fix it. It is a nightmare to debug IPC, because
we have not deployed the proper debug hooks. Let's do it instead, we can
certainly do it in the HPLIP side, and we should have more than enough peer
pressure to make it happen into the PyQT side if we need to get code merged
in there, too.
I think I/we can get the PyQt people to respond, _if_ I could manage a simple example (haven't yet).
Or all IPC should drop PyQt and be done through another library, if they
don't get their act together. It is not like hplip needs advanced IPC, it
just needs to be able to open pipes to children after a fork() and also use
sockets and do select() or pool() on them. Heck, it doesn't even need to
send file handles over the sockets or shared memory pools, signals and other
traditionally hairy stuff. It is just straight data flows, and message
packets. If PyQT can't get this right, well, barebones python certainly
should.
The reason that PyQt is involved with IPC at all is that I have to be able to respond to I/O on the IPC socket in the PyQt/Qt message loop. PyQt doesn't provide any other services beyond providing a callback when data is ready to read on the IPC socket.
Also, should you think the PyQT problem is only related to faxing, well...
hp-toolbox will spin around at 100% CPU busy loops while waiting IPC
messages sometimes (it is not locked, it responds well, and if you close it,
the 100% busy loop goes away, and nothing is left stuck). hp-sendfax does
things that look like this too. The issue is spread all over hplip.
We've never seen this behavior (at least in the last year). Is there any way you could show us how to duplicate it or test it?
Thanks,
Don
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel
