I've been in contact with a couple of backend authors, who expressed
concerns about this release. Let's back the schedule by two weeks, and
give things some time to stabilize.
Revised timetable:
Jan 30, 2011: Feature freeze (only bugs + documentation updates)
Feb 06, 2011: Code freeze (only
Nicolas Martin nicolas0martin at gmail.com wrote:
Hi,
What is weird here, is that the effect of overlap in memcpy does not
seem to produce the same effect on different systems !
Using memcpy() on overlapping memory areas is undefined behaviour per
spec.
glibc has several memcpy()
Hi,
Thanks for this pointer, very interesting and commented
So we have to be double careful when using memcpy though, even if it
acts faster than its cousin memmove !
Nicolas
Le samedi 08 janvier 2011 ? 09:43 +0100, Julien BLACHE a ?crit :
Nicolas Martin nicolas0martin at gmail.com wrote:
On Fri, Jan 7, 2011 at 5:03 AM, Tomas Pospisek tpo_deb at sourcepole.ch wrote:
On Wed, 5 Jan 2011, Julien BLACHE wrote:
m. allan noah kitno455 at gmail.com wrote:
I also have a report for the AV120 (#548731).
I've not heard from Nicholas.
The pixma fix is still in work, IIRC we should
After pulling commit e72c0f548eebfae0171ab8a2e2a74174c1bd96ae, the pixma
backend works correctly with my MX850; there is no corruption, even on
widths indivisible by 32.
Thanks!
- Dustin DeWeese
On 01/06/2011 04:19 PM, Nicolas Martin wrote:
AFAIK, I've currently only heard about this pending
Thanks Dustin for your feedback.
The issue of memmove vs memcpy appears in the last phase of image
processing, to reduce the scanned line width, in order to get an exact
scanned area width, and get rid of the Pixma modulo 32 line width.
Il this case, the cropped line is copied above the scanned
AFAIK, I've currently only heard about this pending issue for the pixma
backend, reported by Dustin DeWeese:
https://alioth.debian.org/tracker/?func=detailatid=410366aid=312874group_id=30186
Maybe Dustin could give us more info about his current test status,
using the latest git ?
Nicolas
Le
Is the generational patch that Gernot discovered in git right now?
allan
On Thu, Jan 6, 2011 at 4:19 PM, Nicolas Martin nicolas0martin at gmail.com
wrote:
AFAIK, I've currently only heard about this pending issue for the pixma
backend, reported by Dustin DeWeese:
On Thu, 6 Jan 2011, m. allan noah wrote:
Is the generational patch that Gernot discovered in git right now?
Yes, it is in. Sorry for the confusion and thanks Nicolas, Gernot
Julien.
*t
On Thu, Jan 6, 2011 at 4:19 PM, Nicolas Martin nicolas0martin at gmail.com
wrote:
AFAIK, I've currently
On Sun, Jan 2, 2011 at 8:38 AM, Julien BLACHE jb at jblache.org wrote:
avision is not yet back to working order as it was prior to Rene's last
code drop that broke everything.
Same for epson2, there are a number of bugs that still need to be fixed
to get it back to a usable state.
pixma
m. allan noah kitno455 at gmail.com wrote:
Hi,
J- I think we need give the backend authors some help with more
specifics. Alessandro thinks only the Perfection 610 is still broken,
The 640u is reportedly still broken (#583166), Olaf says it doesn't like
the area setting; the exchange was
There is quite a bit of updated code (and many months) since our last
release. In particular, there have been some bug fixes to regressions
in the avision and epson2 backends, and some major additions to other
backends (genesys, pixma, etc). If those developments are stable, I
think it's time for
m. allan noah kitno455 at gmail.com wrote:
Hi,
release. In particular, there have been some bug fixes to regressions
in the avision and epson2 backends, and some major additions to other
avision is not yet back to working order as it was prior to Rene's last
code drop that broke everything.
13 matches
Mail list logo
