Re: please push ruby1.9 1.9.0.2-4 to testing

[Adeodato Simó <dato@net.com.org.es>]

* Lucas Nussbaum [Wed, 16 Jul 2008 13:34:19 +0200]:

Hi Lucas,

> Please push ruby1.9/1.9.0.2-4 to testing. It fixes an RC bug (#488432).
> (a force hint is required because the hppa build is missing).

Hint added.

> ruby1.9 FTBFS on hppa (see #478717). The version currently in testing is
> already missing the hppa build, and there's no plan to solve that on our
> side. (it requires help from hppa porters).

Ok, but this presumably means that the hppa version in testing is
vulnerable to the above bug, which I don't think it's acceptable
releasing with.

If ruby1.9 can't be built on hppa anymore, and no porter wants to work
on it, then, given that ruby1.9 is a development version of Ruby (well,
the description says that, is this still true?), I'm ok with releasing
without hppa binaries at all. But this requires work:

  * for the ruby1.9/hppa binaries to be removed from testing, no package
    can be left depending on it, which means all such packages have to
    disappear (from hppa) as well

  * such removals are to be done by the ftp team; I can coordinate with
    them to get them done, so don't worry about that bit

  * however, every source package for which some binary gets removed
    could need work, in order to be buildable again. In particular:

    - source packages which get all its binaries removed (that is, they
      only produce packages that depend on ruby1.9) need no changes if
      they build-depend on ruby1.9(-dev or the like). If they don't,
      they just should gain a build-dependency on it, it's the easiest
      thing to do.

    - source packages that preserve some of its binary packages have to
      be updated not to create the ruby1.9-depending binaries on hppa,
      and to not build-depend on ruby1.9 on hppa. This is done with the
      usual "Build-Depends: ruby1.9-dev [!hppa]", and the -N flag to
      debhelper.

The normal workflow is "fix packages, removals from unstable, removals
from testing", because doing the removals from unstable first just
leaves packages insta RC-buggy. But that workflow makes things harder
for us transition-wise, so I'm going to suggest that we do removals from
unstable first, *once you tell me all uploads are ready in the form of
.dsc*, for immediate dputting once we're done.

So, please let me know if the plan outlined above sounds sensible to
you, and if there would be people that could prepare the uploads to a
staging area.

The list of packages is (fwiw several have pkg-ruby-extras-maint in
Uploaders):

    Michael Ablassmeier <abi@debian.org>
      ncurses-ruby

    Rudi Cilibrasi <cilibrar@debian.org>
      libgpgme-ruby

    Debian GIS Project <pkg-grass-devel@lists.alioth.debian.org>
      mapserver

    Debian Ruby Extras Maintainers <pkg-ruby-extras-maintainers@lists.alioth.debian.org>
      libdb-ruby

    Nico Golde <nion@debian.org>
      stfl

    Ari Pollak <ari@debian.org>
      libhpricot-ruby

    Tatsuki Sugiura <sugi@nemui.org>
      libfcgi-ruby

    Debian RRDtool Team <rrdtool@ml.snow-crash.org>
      rrdtool

    Paul van Tilburg <paulvt@debian.org>
      libcairo-ruby

    Torsten Werner <twerner@debian.org>
      libinotify-ruby

(Ok, they all need uploads, there is none of them of the first type
explained above. Filing bugs at important severity, and explicitly
asking for uploads into gluck:~adeodato/ruby1.9_packages sounds like a
good idea to me.)

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
                               Listening to: Alanis Morissette - Wake up