2018-06-13 20:39 GMT+02:00 Matey Chopov <matey.cho...@ca.abb.com>:
> Hi,
>
> It looks like it happens with a specific .pdf manual, I tested it with
> another .pdf file and the exception didn't occur, the file got pushed
> correctly.
>
> Here's the line in the trace I think is the most interesting:
>
> DatabaseError: (DatabaseError) file is encrypted or is not a database
> u'SELECT ui.ui_id AS ui_ui_id, ui.ui_section AS ui_ui_section, ui.ui_key AS
> ui_ui_key, ui.ui_value AS ui_ui_value, ui.ui_active AS ui_ui_active \nFROM ui
> \nWHERE ui.ui_key = ?' ('push_ssl',)
> 2018-06-13 11:07:04.946 ERROR [waitress] Exception when servicing
> <waitress.channel.HTTPChannel connected 0.0.0.0:12756 at 0x7f06c5923e90>
>
> I have uploaded the surrounding log on pastebin: https://pastebin.com/n9fY4xae
>
> So the problematic pdf that I though wasn't encrypted, was actually encrypted
> with RC4, the weird thing is that in Git Extensions you can still see the
> file contents in the "diff" section.
>
> Apparently, pdf readers automatically decrypt such files if there is no
> password (which is the current case).
>
> I used qpdf to decrypt the file (with no password) which gave another valid
> .pdf file with no encryption (at least that's what I get when I analyze the
> file with pdfinfo).
>
> Tried pushing that file too, but it still failed.
>
> I played with the pdf headers, changed the Creator and Producer values to the
> ones of a .pdf file I know could be uploaded. Same error.
>
> I tried converting the file from pdf1.3 to pdf1.4, same issue.
>
> So, what finally worked for me was converting from pdf to ps, then to text,
> then from the text file, to ps, and then to pdf. The indexing table got
> screwed, but that doesn't really bother me. Finally, pushed the new pdf file
> to the git repo with success.
>
> Commands:
>
> pdftops test.pdf test.ps
> ps2txt test.ps test.txt
>
> enscript -B --margins=10:10 -o test.ps -f Courier@7.3/1 test.txt
> ps2pdf test.ps test_last.pdf
>
Your log also shows:
Traceback (most recent call last):
File "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/task.py",
line 74, in handler_thread
task.service()
File "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/channel.py",
line 368, in service
request._close()
File "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/parser.py",
line 249, in _close
body_rcv.getbuf()._close()
File "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/buffers.py",
line 303, in _close
buf._close()
File "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/buffers.py",
line 110, in _close
self.file.close()
IOError: [Errno 9] Bad file descriptor
which reminds me of following two open issues:
https://bitbucket.org/conservancy/kallithea/issues/219/waitress-exception-when-serving-file
https://bitbucket.org/conservancy/kallithea/issues/229/bad-file-descriptor
Is the PDF on which you see the issue something you could share?
Or could you create another PDF with dummy data that also exhibits the issue?
If at all it would be possible, could you test with the default branch
of Kallithea, instead of 0.3.5 ?
Thanks,
Thomas
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
