Port apache2 2.2.3 from feisty back to dapper

[Graeme Mathieson]

Please could you port Apache2 2.2.3 back from feisty to dapper? I'd really like access to mod_proxy_balancer... I'm currently attempting the backport myself with prevu, but I haven't tried using it before and wouldn't mind somebody a little more familiar with the process producing a good quality package.

[Graeme Mathieson (mathie)]

For what it's worth, I seem to have successfully backported it using prevu, once I had also backported libapr and apr-util from feisty.

[Automated Backports Builder (john-dong+backport-builder)]

This is a notification that the automatic backport of apache2 from gutsy to dapper has started.

You will be notified again once the build is finished.

For additional info and build logs, please see: http://sharkattack.media.mit.edu/inventory/check_builds/52

Thanks,

The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

Howdy! This message is to inform you that the build you requested of apache2 from gutsy to dapper has been completed.
Its status is: FAIL
For further information, build logs, and testing .deb packages, please see: http://sharkattack.media.mit.edu/inventory/check_builds/52

Thanks,
The Backports Builder

[chantra (chantra)]

   -> Trying libaprutil1-dev
       -> Cannot install libaprutil1-dev; apt errors follow:
Reading package lists...
Building dependency tree...
E: Couldn't find package libaprutil1-dev
lsb-release is already the newest version.
W: Unable to locate package libaprutil1-dev
E: Could not satisfy build-dependency.

Seems like it is only a few dependencies away ;)

[Neil Wilson (neil-aldur)]

Yep. Need to build 'apr' and 'apr-util' first. Pity that sharkattack doesn't try that for you automatically.

I've switched to manual 'prevu'. It seems easier.

[Automated Backports Builder (john-dong+backport-builder)]

This is a notification that the automatic backport of apr from gutsy to dapper has started.

You will be notified again once the build is finished.

For additional info and build logs, please see: http://sharkattack.media.mit.edu/inventory/check_builds/56

Thanks,

The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

Howdy! This message is to inform you that the build you requested of apr from gutsy to dapper has been completed.
Its status is: SUCCESS
For further information, build logs, and testing .deb packages, please see: http://sharkattack.media.mit.edu/inventory/check_builds/56

Thanks,
The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

This is a notification that the automatic backport of apr-util from gutsy to dapper has started.

You will be notified again once the build is finished.

For additional info and build logs, please see: http://sharkattack.media.mit.edu/inventory/check_builds/57

Thanks,

The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

Howdy! This message is to inform you that the build you requested of apr-util from gutsy to dapper has been completed.
Its status is: FAIL
For further information, build logs, and testing .deb packages, please see: http://sharkattack.media.mit.edu/inventory/check_builds/57

Thanks,
The Backports Builder

[Neil Wilson (neil-aldur)]

Sharkattack obviously doesn't like multiple package builds!

'apr', 'aprutil' and 'apache2' confirmed as building on Dapper from the Feisty packages via prevu.

Add the following to /etc/apt/sources.list to pick up the test packages.

deb http://accounts4free.rubyforge.org/ubuntu dapper main

Please test installation.

[Scott Kitterman (kitterman)]

Setting to incomplete until the pre-requisite packages are backported. Please file/test backports bugs for those.

[Lionel Porcheron (lionel.porcheron)]

This request has already been rejected in the past.

Considering the number of modules you have to backport (43 at first approximation) and the time needed for apache2.2 transition during feisty dev cycle (we spent something like one moth tracking unmet dep) backporting this backport too risky for me.

Let's see what other think... Scott ? :)

[Neil Wilson (neil-aldur)]

I appreciate the concern. However this is required in live operation,
and is being done manually by Ruby on Rails houses the world over. So
it can't be that much of a problem otherwise people wouldn't be
building businesses on the back of it.

Certainly I don't hear a lot of complaints of shared library failures,
(but that may be because that bit of the package isn't running.)

Perhaps the dependencies within apache2 are too tight, or perhaps the
package could do with splitting. Running a backport could help bring
that to light.

Real businesses like to use 6.06 LTS for all the usual good reasons of
stability and security. It seems a bit of a failure of free software
that they have to look to unofficial archives, and manual compliation
to get the job done.

What do you need to see to get this through?

On 8/2/07, Lionel Porcheron <email address hidden> wrote:
> This request has already been rejected in the past.
>
> Considering the number of modules you have to backport (43 at first
> approximation) and the time needed for apache2.2 transition during
> feisty dev cycle (we spent something like one moth tracking unmet dep)
> backporting this backport too risky for me.
>
> Let's see what other think... Scott ? :)
>
> --
> Port apache2 2.2.3 from feisty back to dapper
> https://bugs.launchpad.net/bugs/80609
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Automated Backports Builder (john-dong+backport-builder)]

This is a notification that the automatic backport of pcre3 from feisty to dapper has started.

You will be notified again once the build is finished.

For additional info and build logs, please see: http://sharkattack.media.mit.edu/inventory/check_builds/59

Thanks,

The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

Howdy! This message is to inform you that the build you requested of pcre3 from feisty to dapper has been completed.
Its status is: SUCCESS
For further information, build logs, and testing .deb packages, please see: http://sharkattack.media.mit.edu/inventory/check_builds/59

Thanks,
The Backports Builder

[Scott Briggs (scott-br)]

I don't really see why this backport has been rejected considering that 6.06 is supposed to be a long-term distribution and 2.2 is a fairly important upgrade over 2.0, at least from a Rails perspective.

As Neil pointed out, companies have been backporting this on their own and using it successfully, so if that's the case, why would it be so difficult creating an official backport?

[Scott Kitterman (kitterman)]

As long as all the rdepends are tested it ought to be feasible.

[Neil Wilson (neil-aldur)]

Would that be rdepends within dapper/main?

On 8/2/07, Scott Kitterman <email address hidden> wrote:
> As long as all the rdepends are tested it ought to be feasible.

[Scott Kitterman (kitterman)]

Main and Universe. Multiverse too if relevant, but I care less about that.

[Neil Wilson (neil-aldur)]

I didn't think Universe was on in Dapper.

On 8/2/07, Scott Kitterman <email address hidden> wrote:
> Main and Universe. Multiverse too if relevant, but I care less about
> that.

[Scott Kitterman (kitterman)]

It's not enabled by default, but it's available. It's also, like backports, only community supported and not covered by Canonical's LTS support.

[Neil Wilson (neil-aldur)]

Thinking about this a little more, I have a feeling that we are coming
at this from different directions.

If it is the case that a backport has to be a drop in replacement for
what is currently in the distribution, then backporting Apache2.2
would be totally impractical. It conflicts with a lot of modules which
don't have Feisty replacements - libapache2-mod-python24 and
libapache2-mod-php4 for starters.

If 'complete backward compatible replacement' is the policy for
backports then that precludes movement from anything much more than
the +1 release because as time moves on too much needs to be
recompiled and it becomes a waste of effort. It also means that
backports to LTS releases become less and less likely, so the LTS
wastes away.

The obvious solution to that is to make sure that LTS releases happen
at intervals much less than the actual support period so that LTS
upgrades can be planned in. Perhaps somebody would be good enough to
ask the question as to when the next LTS can be expected.

The alternative is to see backports as 'augmentation' - particularly
as with Dapper there is a perfectly good and commercially supported
version of apache2 in the distribution. Unlike Feisty, Dapper has
Apache 2.0 at its disposal. You would only go to 2.2 if you needed its
facilities (the case in point being the mod-proxy-balancer widely used
in Rails houses) and the mods you need have been backported. If not
then you get the job of doing the backport on the bit you require!

If you take the 'augmentation' position then you only require a small
number of modules in the backport. Existing modules will conflict
correctly, and yes it may break Bugzilla - but I would suggest that it
is the job of the people who want to run Bugzilla with 2.2 to do the
backport work required to make that combination work on Dapper, not
me. (It may work flawless out of the box. I don't know.).

There is a set of backported Dapper apache2.2 packages on kodefoo
(http://packages.kodefoo.com/dists/dapper/main/binary-i386/Packages)
that has worked fine all year on commercial services supporting Rails,
php5 and perl. That's a lot of real world testing backing up the port.

The only reason for getting these into dapper-backports is to refocus
the community on a single set of auto-built backport packages, get any
bugs tracked in the right place and generally save a lot of messing
around with apt-keys or compilations. But if it is going to be a lot
of trouble requiring extensive testing of package combinations no
sensible sysadmin is going to use then we're not going to save any
community time going down this route. kodefoo works after all and PPAs
are just around the corner.

So if policy dictates complete backward compatibility then we need to
move to WONTFIX straight away. However if there is room for an
augmentation approach, I would suggest a subset similar to the kodefoo
archive would be the pragmatic way forward - and would limit the work
required on all sides. I doubt that implementing such a small subset
would cause much in the way of bug reports (except possibly by those
who haven't pinned their backports properly), but it would be of great
value to the Rails community. ...

[Scott Kitterman (kitterman)]

The next LTS is supposed to be Gutsy + 1.

This is a hard sort of problem for backports. I'm currently working to get clamav 0.9x backported and 0.8x is completely unsupportable. We are working through the various rdpends and figuring out what works and what doesn't. Once we have that worked out, we'll need to decide what we can fix up and what breaks.

I don't think it requires "extensive testing", just some basic functionality testing. Backports does have it's risks. The current policy is essentially, first do no harm. So it needs to either be tested (to some degree) and backported in mass if needed or deferred. I don run web servers, so I can't say how feasible it is to do that testing/coordinated backporting, but that's pretty much what has to happen unless the policy is changed.

[Neil Wilson (neil-aldur)]

It's good to know that a new LTS is around the corner.

It seems to me that you have a 'complete replacement' policy. If that
policy won't flex then this bug is a WONTFIX.

The difference with apache is that 2.0 *is* supportable and entirely
usable, unless you need the new features. So if something breaks you
back out.

Apache2.2 has been tested extensively on dapper by dozens of Rails
users across the world, in the limited context of a load-balancing
webserver and with a limited set of backported packages. It is a
useful addition to dapper and would probably only be used by that set
of people - although it would give others the opportunity to build on
the work.

On 8/3/07, Scott Kitterman <email address hidden> wrote:
> The next LTS is supposed to be Gutsy + 1.

[Automated Backports Builder (john-dong+backport-builder)]

This is a notification that the automatic backport of apache2 from gutsy to dapper has started.

You will be notified again once the build is finished.

For additional info and build logs, please see: http://sharkattack.media.mit.edu/inventory/check_builds/52

Thanks,

The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

Howdy! This message is to inform you that the build you requested of apache2 from gutsy to dapper has been completed.
Its status is: FAIL
For further information, build logs, and testing .deb packages, please see: http://sharkattack.media.mit.edu/inventory/check_builds/52

Thanks,
The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

This is a notification that the automatic backport of apr from gutsy to dapper has started.

You will be notified again once the build is finished.

For additional info and build logs, please see: http://sharkattack.media.mit.edu/inventory/check_builds/56

Thanks,

The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

Howdy! This message is to inform you that the build you requested of apr from gutsy to dapper has been completed.
Its status is: SUCCESS
For further information, build logs, and testing .deb packages, please see: http://sharkattack.media.mit.edu/inventory/check_builds/56

Thanks,
The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

This is a notification that the automatic backport of apache2 from gutsy to dapper has started.

You will be notified again once the build is finished.

For additional info and build logs, please see: http://sharkattack.media.mit.edu/inventory/check_builds/52

Thanks,

The Backports Builder

[Automated Backports Builder (john-dong+backport-builder)]

Howdy! This message is to inform you that the build you requested of apache2 from gutsy to dapper has been completed.
Its status is: FAIL
For further information, build logs, and testing .deb packages, please see: http://sharkattack.media.mit.edu/inventory/check_builds/52

Thanks,
The Backports Builder

[Launchpad Janitor (janitor)]

[Expired for Dapper Backports because there has been no activity for 60 days.]