[Pkg-haskell-maintainers] Bug#691600: libghc-warp-dev: does not parse request headers correctly

[Joachim Breitner]

Hi,

Am Samstag, den 27.10.2012, 18:50 +0200 schrieb Joachim Breitner:
> Am Sonntag, den 28.10.2012, 00:14 +0900 schrieb YOSHINO Yoshihito:
> > On Sat, Oct 27, 2012 at 11:40 PM, Joachim Breitner <nomeata at debian.org> wrote:
> > > I see. Can you elaborate on the severity of the problem? Do such request
> > > headers occur in common situations, or is it just a theoretical problem?
> > 
> > Actually I have stuck in a warp server receiving request from Japanese
> > mobile phones,
> > which send a header with no space between colon and value.
> > 
> > >
> > > It seems that we’d have to backport these two patches:
> > > https://github.com/yesodweb/wai/commit/a827f54ac31e2c928144bb8bb5b92ca1249013c5
> > > https://github.com/yesodweb/wai/commit/dc4697c007beaf1846872744b83162e7c9406465
> > > or am I missing something?
> > 
> > Looks ok.
> 
> I checked, the patches apply cleanly against the version in unstable.
> Unfortunately, I cannot build it because
> libghc-blaze-builder-conduit-doc and libghc-network-conduit-doc are not
> installable in unstable any more.
> 
> So basically now my worries have come true. Just the moment we broke
> stuff in unstable in a way that prevents us from uploading a single fix
> to testing via unstable an allegedly release critical bug comes up.
> 
> I guess I’ll have to setup a wheezy chroot and see if I can build the
> package there.

Ok, the package builds in a wheezy chroot. Unfortunately, the ABI hash
changes¹, so it is not enough to just upload this package to unstable or
testing-proposed-updates.

@release-team: There is a reportedly grave bug with haskell-warp, and a
fix is available. Unfortunately, the route of updating testing via
unstable is broken, some uploads aimed for experimental have ended up in
unstable²

So how can we get the bugfix into wheezy (if you deem it important
enough to be fixed at this stage of the freeze – do you)?

Can we do binNMUs in testing? If yes, then I guess I could upload the
patched package (diff attached) to testing via t-p-u and once it is
there, schedule binNMUs for all depending packages. If not it would
require sourceful uploads of all depending packages, also via t-p-u

Ah, in this case, things are not so bad; haskell-warp is quite low in
the dependency tree. Packages that would require a binNMU or a souceful
no-change-upload are just:
        libghc-warp-tls-dev
        libghc-yesod-dev
        libghc-yesod-default-dev
        

Thanks,
Joachim

¹ This could be considered a bug in GHC, but nothing to be fixed easily
and unfortunately also something that is not as bad for everyone else as
it is for us, it seems: http://hackage.haskell.org/trac/ghc/ticket/4012

² haskell-blaze-builder and haskell-network-conduit, to be precise. The
next time we’ll do a staging in experimental I’ll ask for an upload
block to avoid this. Human error just always needs to be accounted for.


-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: haskell-warp-691600-bugfix.diff
Type: text/x-patch
Size: 10067 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-haskell-maintainers/attachments/20121027/313708c5/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-haskell-maintainers/attachments/20121027/313708c5/attachment-0001.pgp>