Re: problem with recipe build
On Fri, 2012-03-02 at 22:02 -0500, Scott Moser wrote:
> On Fri, 2 Mar 2012, James Westby wrote:
> > On Fri, 2 Mar 2012 17:15:24 -0500 (EST), Scott Moser
> > wrote:
> > > I'm sure I'm doing something wrong, but not sure what.
> > > I'm trying to just set up a launchpad build of two branches, one 'trunk'
> > > that launchpad is pulling from an svn repo, and a packaging only branch.
> > >
> > > I'm not quite sure why there would be expected to be a tag
> > > 'upstream-0.9.4+r4177' as that string is something that was created due to
> > > this build recipe. But the working-dir has in it a directory named
> > > 'madwifi-0.9.4+r4177' and debian/changelog in that says:
> > > | madwifi (0.9.4+r4177-0ubuntu0+7) precise; urgency=low
> > > |
> > > | * Auto build.
> > > |
> > > | -- Scott Moser Fri, 02 Mar 2012 16:58:43 -0500
> > >
> > > Which seems sane to me. The upstream source doesn't have tags named
> > > 'upstream-', but only 'release-'.
> > >
> > > Help?
> >
> > [...]
> >
> > > bzr: ERROR: Unable to find the upstream source. Import it as tag
> > > upstream-0.9.4+r4177 or build with --allow-fallback-to-native.
> >
> > Your version number is saying this is a non-native package, which
> > requires an upstream tarball to build against.
>
> Well, its not a native package, so it makes sense (to me) that the
> version number would reflect that.
Non-native packages require a .orig.tar.gz. bzr-builder tries to
retrieve the contents of that tarball by taking the contents of the tree
at that particular tag.
> > bzr-builder expects that tarball to have been imported by bzr-builddeb,
> > which would have created that tag.
> >
> > You can fix this by either:
> >
> > * Importing the upstream tarball
>
> I really just must be missing something.
>
> The point of this exercise is to get a per-commit build of upstream. For
> each commit upstream, there isn't going to be a upstream tarball to
> import. I could 'import-upstream 0.9.4 madwifi-0.9.4.tar.gz', but in
> testing here, that made no difference.
>
> In an attempt to debug this, I tried to go to the only other daily build
> recipe that I've done:
> https://code.launchpad.net/~smoser/+recipe/euca2ools-daily
>
> I put the following into a recipe (euca.recipe) and issued
> $ sed 's,^,| ,' euca.recipe
> | # bzr-builder format 0.3 deb-version
> | # 2.0.0~bzr{revno}~{revno:packaging}-0ubuntu2
> | lp:euca2ools
> | nest-part packaging lp:~smoser/ubuntu/oneiric/euca2ools/upstream-pkg debian
> debian
> $ bzr dailydeb euca.recipe working-dir
>
> Now, this recipe has built successfully the last trunk commit (516) to
> euca2ools on launchpad. But locally, I see the same error:
>
> bzr: ERROR: Unable to find the upstream source. Import it as tag
> upstream-2.0.0~bzr516~42 or build with --allow-fallback-to-native.
>
> The full output can be seen at http://paste.ubuntu.com/866071/ .
>
> > * Changing the version number to have no "-", making it a native
> > version number.
> > * Or build with --allow-fallback-to-native, which will ignore all of
> > this and build the native package despite the version number
What is the source format the package uses? Is it "3.0 (quilt)" perhaps?
> I did verify that '--allow-fallback-to-native' worked, but it is just
> confusing to me, as this is clearly not a native package, and somehow the
> recipe above works, and works on launchpad.
This makes sense, as Launchpad has --allow-fallback-to-native enabled by
default.
Cheers,
Jelmer
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: problem with recipe build
On 03/05/2012 03:37 PM, Scott Moser wrote:
On Sat, 3 Mar 2012, Jelmer Vernooij wrote:
On Fri, 2012-03-02 at 22:02 -0500, Scott Moser wrote:
Which seems sane to me. The upstream source doesn't have tags named
'upstream-', but only 'release-'.
Help?
[...]
bzr: ERROR: Unable to find the upstream source. Import it as tag
upstream-0.9.4+r4177 or build with --allow-fallback-to-native.
Your version number is saying this is a non-native package, which
requires an upstream tarball to build against.
Well, its not a native package, so it makes sense (to me) that the
version number would reflect that.
Non-native packages require a .orig.tar.gz. bzr-builder tries to
retrieve the contents of that tarball by taking the contents of the tree
at that particular tag.
That does make sense. I just was expecting that the daily build code for
a non-native version string would essentially do:
$ bzr branch $UPSTREAM_BRANCH upstream
$ ( cd upstream&& bzr export \
--root ${PKG_NAME}-${UPSTREAM_VERSION_PART}> \
../${PKG_NAME}_${UPSTREAM_VERSION_PART}.orig.tar.gz )
Where UPSTREAM_VERSION_PART in this case would be '0.9.4+r4177'.
And the error message does suggest the right path, but it just seemed
wrong.
The recipe doesn't know the upstream branch, so it doesn't have a way to
do this. It is just a set of operations to combine branches, none of
them really have any special properties.
I did verify that '--allow-fallback-to-native' worked, but it is just
confusing to me, as this is clearly not a native package, and somehow the
recipe above works, and works on launchpad.
This makes sense, as Launchpad has --allow-fallback-to-native enabled by
default.
That makes sense as to why it builds.
Is the following basic form for an upstream build sane:
| # bzr-builder format 0.3 deb-version
| # 2.0.0~bzr{revno}~{revno:packaging}-0ubuntu2
| lp:euca2ools
| nest-part packaging lp:~smoser/ubuntu/oneiric/euca2ools/upstream-pkg debian
debian
Yep, that makes sense. I would generally put ~{revno:packaging} after
the debian revision though, as that's what it relates to.
You can also use {debupstream} to extract the upstream version string
from the packaging branch. That way you don't have to update the recipe
each time there is a new upstream version.
E.g.:
{debupstream}~bzr{revno}-0ubuntu2~bzr{revno:packaging}
Hope this helps.
Cheers,
Jelmer
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: problem with recipe build
On Sat, 3 Mar 2012, Jelmer Vernooij wrote:
> On Fri, 2012-03-02 at 22:02 -0500, Scott Moser wrote:
> > > > Which seems sane to me. The upstream source doesn't have tags named
> > > > 'upstream-', but only 'release-'.
> > > >
> > > > Help?
> > >
> > > [...]
> > >
> > > > bzr: ERROR: Unable to find the upstream source. Import it as tag
> > > > upstream-0.9.4+r4177 or build with --allow-fallback-to-native.
> > >
> > > Your version number is saying this is a non-native package, which
> > > requires an upstream tarball to build against.
> >
> > Well, its not a native package, so it makes sense (to me) that the
> > version number would reflect that.
> Non-native packages require a .orig.tar.gz. bzr-builder tries to
> retrieve the contents of that tarball by taking the contents of the tree
> at that particular tag.
That does make sense. I just was expecting that the daily build code for
a non-native version string would essentially do:
$ bzr branch $UPSTREAM_BRANCH upstream
$ ( cd upstream && bzr export \
--root ${PKG_NAME}-${UPSTREAM_VERSION_PART} > \
../${PKG_NAME}_${UPSTREAM_VERSION_PART}.orig.tar.gz )
Where UPSTREAM_VERSION_PART in this case would be '0.9.4+r4177'.
And the error message does suggest the right path, but it just seemed
wrong.
> > The full output can be seen at http://paste.ubuntu.com/866071/ .
> >
> > > * Changing the version number to have no "-", making it a native
> > > version number.
> > > * Or build with --allow-fallback-to-native, which will ignore all of
> > > this and build the native package despite the version number
> What is the source format the package uses? Is it "3.0 (quilt)" perhaps?
It is quilt 3.0.
> > I did verify that '--allow-fallback-to-native' worked, but it is just
> > confusing to me, as this is clearly not a native package, and somehow the
> > recipe above works, and works on launchpad.
> This makes sense, as Launchpad has --allow-fallback-to-native enabled by
> default.
That makes sense as to why it builds.
Is the following basic form for an upstream build sane:
| # bzr-builder format 0.3 deb-version
| # 2.0.0~bzr{revno}~{revno:packaging}-0ubuntu2
| lp:euca2ools
| nest-part packaging lp:~smoser/ubuntu/oneiric/euca2ools/upstream-pkg debian
debian
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: problem with recipe build
On Fri, 2 Mar 2012, James Westby wrote:
> On Fri, 2 Mar 2012 17:15:24 -0500 (EST), Scott Moser
> wrote:
> > I'm sure I'm doing something wrong, but not sure what.
> > I'm trying to just set up a launchpad build of two branches, one 'trunk'
> > that launchpad is pulling from an svn repo, and a packaging only branch.
> >
> > I'm not quite sure why there would be expected to be a tag
> > 'upstream-0.9.4+r4177' as that string is something that was created due to
> > this build recipe. But the working-dir has in it a directory named
> > 'madwifi-0.9.4+r4177' and debian/changelog in that says:
> > | madwifi (0.9.4+r4177-0ubuntu0+7) precise; urgency=low
> > |
> > | * Auto build.
> > |
> > | -- Scott Moser Fri, 02 Mar 2012 16:58:43 -0500
> >
> > Which seems sane to me. The upstream source doesn't have tags named
> > 'upstream-', but only 'release-'.
> >
> > Help?
>
> [...]
>
> > bzr: ERROR: Unable to find the upstream source. Import it as tag
> > upstream-0.9.4+r4177 or build with --allow-fallback-to-native.
>
> Your version number is saying this is a non-native package, which
> requires an upstream tarball to build against.
Well, its not a native package, so it makes sense (to me) that the
version number would reflect that.
> bzr-builder expects that tarball to have been imported by bzr-builddeb,
> which would have created that tag.
>
> You can fix this by either:
>
> * Importing the upstream tarball
I really just must be missing something.
The point of this exercise is to get a per-commit build of upstream. For
each commit upstream, there isn't going to be a upstream tarball to
import. I could 'import-upstream 0.9.4 madwifi-0.9.4.tar.gz', but in
testing here, that made no difference.
In an attempt to debug this, I tried to go to the only other daily build
recipe that I've done:
https://code.launchpad.net/~smoser/+recipe/euca2ools-daily
I put the following into a recipe (euca.recipe) and issued
$ sed 's,^,| ,' euca.recipe
| # bzr-builder format 0.3 deb-version
| # 2.0.0~bzr{revno}~{revno:packaging}-0ubuntu2
| lp:euca2ools
| nest-part packaging lp:~smoser/ubuntu/oneiric/euca2ools/upstream-pkg debian
debian
$ bzr dailydeb euca.recipe working-dir
Now, this recipe has built successfully the last trunk commit (516) to
euca2ools on launchpad. But locally, I see the same error:
bzr: ERROR: Unable to find the upstream source. Import it as tag
upstream-2.0.0~bzr516~42 or build with --allow-fallback-to-native.
The full output can be seen at http://paste.ubuntu.com/866071/ .
> * Changing the version number to have no "-", making it a native
> version number.
> * Or build with --allow-fallback-to-native, which will ignore all of
> this and build the native package despite the version number
I did verify that '--allow-fallback-to-native' worked, but it is just
confusing to me, as this is clearly not a native package, and somehow the
recipe above works, and works on launchpad.
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: problem with recipe build
On Fri, 2 Mar 2012 17:15:24 -0500 (EST), Scott Moser wrote: > I'm sure I'm doing something wrong, but not sure what. > I'm trying to just set up a launchpad build of two branches, one 'trunk' > that launchpad is pulling from an svn repo, and a packaging only branch. > > I'm not quite sure why there would be expected to be a tag > 'upstream-0.9.4+r4177' as that string is something that was created due to > this build recipe. But the working-dir has in it a directory named > 'madwifi-0.9.4+r4177' and debian/changelog in that says: > | madwifi (0.9.4+r4177-0ubuntu0+7) precise; urgency=low > | > | * Auto build. > | > | -- Scott Moser Fri, 02 Mar 2012 16:58:43 -0500 > > Which seems sane to me. The upstream source doesn't have tags named > 'upstream-', but only 'release-'. > > Help? [...] > bzr: ERROR: Unable to find the upstream source. Import it as tag > upstream-0.9.4+r4177 or build with --allow-fallback-to-native. Your version number is saying this is a non-native package, which requires an upstream tarball to build against. bzr-builder expects that tarball to have been imported by bzr-builddeb, which would have created that tag. You can fix this by either: * Importing the upstream tarball * Changing the version number to have no "-", making it a native version number. * Or build with --allow-fallback-to-native, which will ignore all of this and build the native package despite the version number Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
problem with recipe build
I'm sure I'm doing something wrong, but not sure what.
I'm trying to just set up a launchpad build of two branches, one 'trunk'
that launchpad is pulling from an svn repo, and a packaging only branch.
I'm not quite sure why there would be expected to be a tag
'upstream-0.9.4+r4177' as that string is something that was created due to
this build recipe. But the working-dir has in it a directory named
'madwifi-0.9.4+r4177' and debian/changelog in that says:
| madwifi (0.9.4+r4177-0ubuntu0+7) precise; urgency=low
|
| * Auto build.
|
| -- Scott Moser Fri, 02 Mar 2012 16:58:43 -0500
Which seems sane to me. The upstream source doesn't have tags named
'upstream-', but only 'release-'.
Help?
$ dpkg-query --show bzr-builder
bzr-builder 0.7.2-0ubuntu1
$ cat madwifi-daily.recipe
# bzr-builder format 0.4 deb-version
0.9.4+r{svn-revno}-0ubuntu0+{revno:packaging}
#/home/smoser/src/madwifi/trunk.dist
lp:~smoser/madwifi/trunk
#merge packaging /home/smoser/src/madwifi/ubuntu.dist
merge packaging lp:~smoser/madwifi/ubuntu
$ bzr dailydeb madwifi-daily.recipe working-dir
Building tree.
Retrieving 'lp:~smoser/madwifi/trunk' to put at
'working-dir/madwifi-daily-0.9.4+r{svn-revno}-0ubuntu0+{revno:packaging}'.
Merging 'lp:~smoser/madwifi/ubuntu' in to
'working-dir/madwifi-daily-0.9.4+r{svn-revno}-0ubuntu0+{revno:packaging}'.
All changes applied successfully.
Committing to:
/home/smoser/src/madwifi/x/working-dir/madwifi-daily-0.9.4+r{svn-revno}-0ubuntu0+{revno:packaging}/
added debian
added debian/README.source
added debian/changelog
added debian/compat
added debian/control
added debian/copyright
added debian/dkms.conf.in
added debian/dkms_dbversion
added debian/madwifi-dkms.install
added debian/madwifi-dkms.postinst
added debian/madwifi-dkms.prerm
added debian/madwifi-tools.install
added debian/patches
added debian/rules
added debian/source
added debian/watch
added debian/patches/no-kernel-headers-required.patch
added debian/patches/series
added debian/source/format
Committed revision 1702.
bzr: ERROR: Unable to find the upstream source. Import it as tag
upstream-0.9.4+r4177 or build with --allow-fallback-to-native.
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
