Re: Couple of optimizations to the foo2hbpl2 driver

2020-02-27 Thread Alexey Charkov
Hi Rick,

Just wanted to follow up on the below - will you have chance to review
the changes and apply to your code if those look good to you?

@Debian printing team, I presume you guys don't apply non-bugfix
changes that are not upstream, but any comments on the code would be
highly appreciated if you have chance to review!

Many thanks,
Alexey


вт, 18 февр. 2020 г. в 01:30, Alexey Charkov :
>
> Hi all,
>
> I've done a couple of optimizations in the foo2zjs package, namely the 
> foo2hbpl2 driver to make it run a bit more smoothly on my 
> resource-constrained print server (DMP Vortex86EX with 128M RAM).
>
> Published them on Github:
>
> https://github.com/alchark/foo2zjs.git
>
> Just wondering what would be the best way to get them integrated? I couldn't 
> find a Git repo with upstream sources, so maybe Rick you could review the 
> changes and apply directly if all looks good to you?
>
> I based the patches on top of the Debian sources (as that's what I'm running 
> on my device), but from what I can tell the only affected file (foo2hbpl2.c) 
> didn't change from the upstream version.
>
> Thanks a lot,
> Alexey



[bts-link] source package src:pyppd

2020-02-27 Thread debian-bts-link
#
# bts-link upstream status pull for source package src:pyppd
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
# https://bts-link-team.pages.debian.net/bts-link/
#

user debian-bts-l...@lists.debian.org

# remote status report for #951313 (http://bugs.debian.org/951313)
# Bug title: pyppd: unarchiving some ppds needs large available memory
#  * https://github.com/vitorbaptista/pyppd/issues/2
#  * remote status changed: open -> closed
#  * closed upstream
tags 951313 + fixed-upstream
usertags 951313 - status-open
usertags 951313 + status-closed

thanks



Processed: [bts-link] source package src:pyppd

2020-02-27 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package src:pyppd
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting user to debian-bts-l...@lists.debian.org (was 
debian-bts-l...@lists.debian.org).
> # remote status report for #951313 (http://bugs.debian.org/951313)
> # Bug title: pyppd: unarchiving some ppds needs large available memory
> #  * https://github.com/vitorbaptista/pyppd/issues/2
> #  * remote status changed: open -> closed
> #  * closed upstream
> tags 951313 + fixed-upstream
Bug #951313 [src:pyppd] pyppd: unarchiving some ppds needs large available 
memory
Added tag(s) fixed-upstream.
> usertags 951313 - status-open
Usertags were: status-open.
Usertags are now: .
> usertags 951313 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
951313: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951313
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#952684: cups: segfault in printers.cgi when browsing finished jobs in the cups webpage

2020-02-27 Thread Bernhard Übelacker
Package: cups
Version: 2.2.10-6+deb10u2
Severity: normal



Dear Maintainer,

I found today some suspicious segfault line in dmesg output and
could reproduce it every time I loaded the finished jobs of a printer
with this URL:

http://localhost:631/printers/Samsung_CLX-3180_Series?which_jobs=completed

This is the dmesg output:

kernel: printers.cgi[3587]: segfault at 0 ip 7f05a859e181 sp 
7fffcf0fb678 error 4 in libc-2.28.so[7f05a8464000+148000]
kernel: Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e 0f 1f 84 
00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77 1f  fd 74 0f 
c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1

Unfortunately no core was collected by systemd-coredump, but
I could generate one manually by running it in gdb described in
attached file.

(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x7f02ba505dae in __GI___strdup (s=0x0) at strdup.c:41
#2  0x556d4f025055 in cgiGetArray (name=name@entry=0x7fffd550ce11 
"job_name", element=element@entry=0) at var.c:171
#3  0x556d4f023cdc in cgi_copy (out=out@entry=0x7f02ba63a760 
<_IO_2_1_stdout_>, in=in@entry=0x556d4f068590, element=element@entry=0, 
term=term@entry=125 '}', indent=indent@entry=4) at template.c:299
#4  0x556d4f0245fe in cgi_copy (out=out@entry=0x7f02ba63a760 
<_IO_2_1_stdout_>, in=in@entry=0x556d4f068590, element=element@entry=0, 
term=term@entry=125 '}', indent=indent@entry=2) at template.c:348
#5  0x556d4f023ee6 in cgi_copy (out=0x7f02ba63a760 <_IO_2_1_stdout_>, 
in=in@entry=0x556d4f068590, element=element@entry=0, term=term@entry=0 '\000', 
indent=indent@entry=0) at template.c:602
#6  0x556d4f024977 in cgiCopyTemplateLang 
(tmpl=tmpl@entry=0x556d4f027091 "jobs.tmpl") at template.c:148
#7  0x556d4f02206e in cgiShowJobs (http=, 
dest=0x7fffd5510ee0 "Samsung_CLX-3180_Series") at ipp-var.c:1506
#8  0x556d4f01f9e6 in show_printer (printer=0x7fffd5510ee0 
"Samsung_CLX-3180_Series", http=0x556d4f06c370) at printers.c:540
#9  main () at printers.c:137

...
(gdb) up
#2  0x556d4f025055 in cgiGetArray (name=name@entry=0x7fffd550ce11 
"job_name", element=element@entry=0) at var.c:171
171   return (strdup(var->values[element]));

I found an upstream change that leaves cgiGetArray
if "var->values[element]" would be a NULL value [1].

This change reached bullseye/testing already, therefore
just buster/stable would be affected [2].

But I am not sure if this is the real problem as the
file /var/spool/cups/c00208 really contains a "job-name",
but no "job_name".

My guess is the "job_name" originates from 
/usr/share/cups/templates/de/jobs.tmpl.
Therefore might this be a internationalisation issue?

A package cups built with the patch in [1] makes the
finished jobs page load completely.

All print jobs show as name unknown ("Unbekannt"),
except some recent test pages.
Most regular prints are done from a kde environment e.g. okular.


So maybe this upstream patch is worth to be considered in stable?

And second, can someone confirm if this unknown name is an issue,
while the file in /var/spool/cups does contain a job-name?
When opening the kde print queue I get the job names - maybe it
is changed to unknown on purpose for security reasons?
In bullseye/testing the web page shows also unknown, even
when credentials were given before and test page is printed
from there. (Should this go into a separate bug?)



Kind regards,
Bernhard


[1] 
https://github.com/apple/cups/commit/eda46e3aac94d42e4199d95befe99ff83afb098f
https://github.com/apple/cups/pull/5621

[2] https://sources.debian.org/src/cups/2.2.10-6+deb10u2/cgi-bin/var.c/#L171
https://sources.debian.org/src/cups/2.3.1-11/cgi-bin/var.c/#L173








-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-7-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client2.2.10-6+deb10u2
ii  cups-common2.2.10-6+deb10u2
ii  cups-core-drivers  2.2.10-6+deb10u2
ii  cups-daemon2.2.10-6+deb10u2
ii  cups-filters   1.21.6-5
ii  cups-ppdc  2.2.10-6+deb10u2
ii  cups-server-common 2.2.10-6+deb10u2
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2+deb10u3
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libcups2   2.2.10-6+deb10u2
ii  libcupsimage2  2.2.10-6+deb10u2
ii  libgcc1   

Bug#952674: New version 0.18 released

2020-02-27 Thread Jonas Smedegaard
Quoting Mathieu Malaterre (2020-02-27 12:55:33)
> Source: jbig2dec
> Version: 0.18
> 
> Version 0.18 has been released on 2020/02/11.

What makes you conclude the above?

Homepage https://jbig2dec.com/ lists 0.17.


> Until the issue with the git tag is resolved, here is it:
> 
> http://git.ghostscript.com/?p=jbig2dec.git;a=commitdiff;h=7e45faa81deadc4a3b4419a9e76a17782e8034f4

Yes, I am aware that 0.18 is being prepared, but not that it is final.

Previously when I've requested formal release tracking and release 
tarballs, I was told that releases are done in relation to Ghostscript 
releases.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#952674: New version 0.18 released

2020-02-27 Thread Mathieu Malaterre
Source: jbig2dec
Version: 0.18

Version 0.18 has been released on 2020/02/11. Until the issue with the
git tag is resolved, here is it:

http://git.ghostscript.com/?p=jbig2dec.git;a=commitdiff;h=7e45faa81deadc4a3b4419a9e76a17782e8034f4