** No longer affects: launchpad
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/766242
Title:
lp:ubuntu/cloud-init is not buildable by bzr-builder
To manage notifications about this bug go to:
https:
generally, i think that bzr-builder should be better, and allow for no
.pc directory but applied patches.
However, cloud-init's ubuntu trunk is now an upstream snapshot, so:
$ cat > cloud-init.recipe <<"EOF"
# bzr-builder format 0.4 deb-version {debupstream}-0ubuntu0+{revno}
lp:ubuntu/cloud-init
E
I'm moving this to confirmed in bzr-builder.
That said, I would be willing to have the lp:ubuntu/cloud-init branch fixed
because I'd like for it to build.
I personally really hate .pc directories being versioned, but would live with
it or consider moving off quilt-3.0.
somewhat related, is that
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/766242
Title:
lp:ubuntu/cloud-init is not buildable by bzr-builder
To manage
On Tue, 17 May 2011, James Westby wrote:
> What is causing the issue is that debuild and bzr-builder apply the
> quilt patches in slightly different ways, with bzr-builder failing if
> the patches are already applied and there is no .pc directory, and
> debuild no failing in that case.
I'd much p
Excerpts from James Westby's message of Tue May 17 02:08:47 UTC 2011:
> On Mon, 16 May 2011 22:18:37 -, Clint Byrum wrote:
> > There's not much we can do if the source package patches conflicts
> > directly with upstream. The build log is quite clear which patches won't
> > apply, so they can
"This is just about rebuilding the current Ubuntu package,"
Exactly.
Nobody is expecting an auto merge here.
This is the standard distribution package as uploaded automatically to
Bzr being built on that distribution by the Launchpad builder system.
And currently for this package it doesn't wor
On Mon, 16 May 2011 22:18:37 -, Clint Byrum wrote:
> There's not much we can do if the source package patches conflicts
> directly with upstream. The build log is quite clear which patches won't
> apply, so they can be selectively removed if some need to stay. Ultimately
> you have 4 different
Excerpts from Neil Wilson's message of Mon May 16 20:26:10 UTC 2011:
> That's hardly user friendly.
>
> Surely if the builder is to be of any use whatsoever it should build the
> Ubuntu source branch with a simple command.
>
> Having to manipulate a source package upload to get it to build is
> t
Hi Jelmer,
Perhaps the applying of quilt patches in bzr-builder can be more graceful in its
handling of this state.
That is:
* patches in debian/patches
* Those patches already applied
* No .pc directory
Thanks,
James
--
You received this bug notification because you are a member of Ub
That's hardly user friendly.
Surely if the builder is to be of any use whatsoever it should build the
Ubuntu source branch with a simple command.
Having to manipulate a source package upload to get it to build is
totally counter-intuitive.
--
You received this bug notification because you are a
Neil, I'm marking this bug as Incomplete. Please try removing the
patches in the build recipe, as the build log you pasted seems to
suggest that they are simply conflicting with the branch content, which
is a normal condition. You can either add 'run rm debian/patches/*', or
create a new branch of
Are you certain this is a problem with the branch?
The branch matches what is in the Ubuntu archives exactly. bzr bd -S
from the branch and apt-get source produce identical
.dsc/.debian.tar.gz/.orig.tar.gz files.
It seems more appropriate then that bzr-builder should be able to read
this the same
13 matches
Mail list logo
