Steve Langasek wrote: > On Fri, Dec 15, 2006 at 08:03:24PM -0600, Adam Majer wrote: >> Err, why was this tla pushed to Etch? I thought Etch was frozen. > > Because seeing that the version in unstable depended on libneon26-gnutls, I > mistakenly assumed that the version in testing was similarly linked and > therefore an update was needed for the neon26 package fixes. Sorry, my > mistake. If you can provide an updated package that reverts to the behavior > in -4, I'll push it in ASAP. This will need to go through unstable first; > since testing and unstable currently have the same version, t-p-u won't > work.
No problem. Uploaded -9 that reverts the libneon patch. I noticed one issue after the upload though. The i386 that I built seems to include additional dependencies not in other builds. Namely there is a dependencies on libcomerr2 (>= 1.33-3), libkrb53 (>= 1.4.2). It seems my build environment causes tla to pick up these dependencies. I'll have to look later at what these actually mean and what functionality is added, but in the mean time, would be possible for the RM to trigger a binary only rebuild on the i386 autobuilder? Or is this something that is easier if I do myself? >> The -4 used embedded libneon. Then it was moved to use libneon26 instead >> which caused a kind of a major regression: > >> #402952: tla: segmentation fault trying to get >> [EMAIL PROTECTED]/emacs--devo--0 > >> Now this has to be fixed for Etch... an error that didn't exist in Etch >> yesterday. If I had known or without freeze, I would have upgraded this >> bug to RC to prevent this transition until the bug is fixed. > > But this one is your mistake. ;) If a bug is RC, please mark it as such to > protect your package from bumbling RMs. Maybe. But generally regression important bugs are not RC bugs AFAIK, although I wish they were. Regression bugs the the worst since these are almost 100% preventable. As a software developer, I hate them with passion! - Adam
signature.asc
Description: OpenPGP digital signature
