{5} Accepted, Active Tickets by Owner (Full Description) (18 matches)
List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.
jerome (18 matches)
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #69 | DockBook warnings | pykota | 1.27 final | defect | 02/07/11 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Trying to build HTML documentation for pykota 1.27 (SVN rev. 3554) with docbook2html from docbook-utils 0.6.14 caused docbook to spit some warnings. Attached patch makes docbook happy. Another problem is that HTML docs don't get installed into /usr/share/doc/pykota/html/ as intended. Fix for that isn't included into the patch, because I didn't know where it fits best. Either change setup.py to search for HTML files in docs/*.html instead of docs/pykota/*.html -docfiles = glob.glob(os.sep.join(["docs", "pykota", "*.html"])) +docfiles = glob.glob(os.sep.join(["docs", "*.html"])) or change debian/Makefile.docs to let it build HTML docs in subdirectory docs/pykota/ instead of docs/ - docbook2html pykota.sgml + docbook2html -o pykota pykota.sgml |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #68 | Pykota mysql connection timeout | pykota | defect | 01/25/11 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
When a print job gets stuck in the queue for a long time, pykota fails. I don't yet know why jobs get stuck. Maybe the printer is out of paper when nobody is around to refill it. When cupspykota is finally able to print, it tries to connect to the mysql database and fails. The connection gets lost after 8 hours due to the default wait_timeout in mysqld. Here is an example of such a job from the logs: messages:Jan 24 16:54:44 <host> PyKota: (PID 31610) : <user>(9389) => Job accounting begins. messages:Jan 24 16:54:50 <host> PyKota: (PID 31610) : <user>(9389) => CUPS backend /usr/lib/cups/backend/socket returned 0. messages:Jan 25 08:26:34 <host> PyKota: (PID 31610) : <user>(9389) => Job accounting ends. error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] PyKota v1.26_official error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] cupspykota backend failed error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] Traceback (most recent call last): error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] File "/usr/lib/cups/backend/cupspykota", line 1474, in ? error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] File "/usr/lib/cups/backend/cupspykota", line 1135, in mainWork error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] File "/usr/lib/cups/backend/cupspykota", line 1271, in doWork error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] File "/usr/lib/python2.4/site-packages/pykota/storages/mysqlstorage.py", line 78, in beginTransaction error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] self.cursor.execute("BEGIN;") error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] File "/usr/lib/python2.4/site-packages/MySQLdb/cursors.py", line 166, in execute error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] self.errorhandler(self, exc, value) error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] File "/usr/lib/python2.4/site-packages/MySQLdb/connections.py", line 35, in defaulterrorhandler error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] raise errorclass, errorvalue error_log:E [25/Jan/2011:08:26:34 -0500] [Job 9389] OperationalError?: (2006, 'MySQL server has gone away') Maybe pykota could try to reconnect to the mysql database in this case? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #80 | Some Zenographics ZJStream print jobs incorrectly detected as PCL3/4/5 | pkpgcounter | defect | 09/21/13 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Some ZJStream files contain a PJL header, making such files be detected as PCL3/4/5 instead of ZJStream, resulting in a inaccurate page count. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4 | Support for CUPS' unix domain sockets | pkipplib | None | enhancement | 06/11/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
pkipplib doesn't support to communicate with CUPS through unix domain sockets, but only through inet domain sockets. This is problematic when people forbid their CUPS+PyKota server to listen to 127.0.0.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #5 | Encryption support | pykoticon | None | enhancement | 06/11/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
PyKotIcon? doesn't encrypt datas when dialoguing with pknotify (or other compatible applications). This is mostly a problem when 'pknotify --checkauth --ask "Password:password"' is used, because the password will fly unencrypted over the network. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #11 | Add a minimal cost per page when using ink accounting | pykota | 1.27 final | enhancement | 06/11/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
With ink accounting almost empty sheets are accounted for almost no credits. A base price per page could be used to set a minimum. Alternatively, the actual computation formula could be modified. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #12 | Revamp the LDAP schema | pykota | None | enhancement | 06/11/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The actual LDAP schema is overly complex : PyKota user account and user's balance are split in two for no valid reason. Last job of each printer is not stored in the printer object itself for no valid reason, and so on... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #13 | Improve the relational schema | pykota | None | enhancement | 06/11/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Additional informations could be stored, like the account balance's value at the time a job was printed, the details of the printed pages (format, orientation, duplex mode...) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #22 | Add support for CUPS' CUPS_FILETYPE environment variable. | pykota | None | enhancement | 09/18/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
An enhancement request (CUPS STR 2799) I had submitted for CUPS has been implemented in CUPS' r7962 : the CUPS_FILETYPE environment variable available to the cupspykota backend (to any backend in fact) contains 'job-sheet' for a banner page, and 'document' for the real job. This means that PyKota can now account differently banner pages and jobs. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #27 | Can not set the Maximum Job Size(kBytes) | pykota | None | enhancement | 10/23/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
PyKota can not set the maximum job size allowed to printer to kBytes per job instead of pages. The CUPS command "lpadmin" just has quota control, the "job-k-limit" base on "job-quota-period". In other words, we can set the maximum job size for a period, and can not set the maximum job size for a single job. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #51 | Export additional environment variables | pykota | 1.27 final | enhancement | 01/21/10 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It would be useful to export additional environment variables, like for example the current user's email address as read from PyKota's database. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #53 | SNMP accounter for HP designjet | pykota | enhancement | 03/25/10 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
HP Designjet har the ability to report paper and ink usage. The attached diff shows how I read the used paper area (in square inch) and convert to A4 pages. //Bse diff /usr/lib/python2.4/site-packages/pykota/accounters/snmp.py snmp_designjet.py.work.without_extra_sleepdelay 56a57
94c95,96 < defaultErrorMask = 0x4fcc # [ 'No Paper', ---
285c287 < tuple([int(i) for i in pageCounterOID.split('.')]), \ ---
320c322 < req.apiAlphaGetPdu().apiAlphaSetVarBindList((pageCounterOID, ver.Null()), \ ---
400c402 < return acc.protocolHandler.retrieveInternalPageCounter() ---
410c412,413 < print "Internal page counter's value is : %s" % pagecounter ---
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2 | Incorrect handling of PJL statements | pkpgcounter | None | defect | 06/03/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
PJL statements appearing, at least, in PCL3/4/5 and PCLXL jobs, before the content of the very first page are not correctly taken into account. They are correctly parsed, but not used when computing number of copies and default page formats... See this thread in Jasmine's mailing list : http://www.mail-archive.com/jasmine@ml.free.fr/msg00179.html Fix is on the way... since December of 2007. PJL parser has been improved, but nothing committed just yet. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #39 | pkpgcounter fails to read PJL-wrapped postscript | pkpgcounter | 1.27 final | defect | 02/24/09 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi, this is a copy of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515184, to be tracked in the proper tracker. Summary: Some ppds create PJL headers for their postscript. This is passed py pkgpgcounter to ghostscript unmodified, causing it to fail. A solution would be to detect the presence of these headers and strip them before sending the file to ghostscript. A simple striper (in perl) is in the patch http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=pkpgcounter.patch;att=1;bug=515184 Greetings, Joachim |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #67 | PJL hardware accounting not working (halts printing) on LaserJet 5 (fix included) | pykota | 1.27 final | defect | 09/15/10 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
A LaserJet? 5 printer will return multiple status messages when, for example, pagecount is requested. It will return first return 10023 (printing) twice, then the pagecount and then 10001 (ready). In this case, 10023 just means "Busy retreiving pagecount", but this is interpreted wrongly by pykota/accounters/pjl.py. The script does not wait for the last status message, but stops looking after receiving the pagecount and the 10023 status. This causes the script to wait on the printer for eternity. Suggested fix: Adding the extra where clause: "or (self.printerStatus == '10023')" to line 146 causes the script to wait until the timeout to see if there are any other incoming status messages. With this fix it picks the first non-10023 status code, or just 10023 after the timeout. Increasing any of the timeout values was not needed for my printer. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #26 | Switch autocommit mode off for relational backends. | pykota | None | enhancement | 10/04/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Some RDBMS don't have an explicit way to begin a transaction (like DB2). Actually all relational backends set automatic commit mode to on, but this won't be possible for DB2 and probably other backends. PyKota's code must be changed to handle this problem which prevents PyKota from being ported to other RDBMS. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #34 | Die gracefully or print when database is not available | pykota | None | enhancement | 12/05/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
When the cupspykota backend runs, we know that we need read+write access to the database. Introduce a printingwithnodb directive which allows either print or fail (and possibly ignore which is fail with an exit(0)), as values in pykota.conf. This directive will let PyKota know if it has to fail (as it does actually), or print anyway if the database isn't available. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #70 | pynotify is not raising the dialog box | pykoticon | defect | 02/15/11 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I am using Kubuntu 10.04 and installed pykota-1.26_fixes_official at my system. All is working except from the pknotify problem. It seems pknotify is not raising the dialog boxes in front of other windows so when i sent the print request i can not see the dialog box, but can understand the pykoticon is received the request from the line "127.0.0.1 connected". Also i can take the opened dialog box to the front by using alt+tab and see the dialog screen. When i confirm the dialog, i can see the printing is processing. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
