PPA should be able to use 'proposed' pocket build context

[David D Short]

I get this error when my package tries to build itself for the PPA:

"linux-libc-dev(inst 2.6.24-19.36 ! >= wanted 2.6.24-20.37)"

I have version 2.6.24-20.37 of linux-libc-dev on my machine and it came from backports, see https://edge.launchpad.net/ubuntu/hardy/i386/linux-libc-dev. However the builder is only able to get version 2.6.24-20.36 (from updates/security)

[Julian Edwards (julian-edwards)]

The build machines are "stuck" on 2.6.24-19.36 because they do not use the proposed pocket, unlike your own machine.

2.6.24-20.37 is only available in -proposed.

[David D Short (chameleondave)]

That's not a helpful response.

[Celso Providelo (cprov)]

David,

What Julian meant was that packages published in the 'proposed' pocket of ubuntu primary archive are not considered when building PPA sources.

We currently only consider 'release', 'updates' and 'security' for building PPA and that can be seen on top of the buildlog.

As you might have notice 'backports' pocket is also missing, as mentioned in bug #246685.

We have plans to allow PPA administrators to include 'proposed' and 'backports' contexts when they need it (as you can do with the current PPA dependencies), assuming that they know the implications of doing that (building sources with bleeding-edge and probably broken dependencies).

Anyway, I will modify the bug title and reopen this bug to not let you down, okay ?

[David D Short (chameleondave)]

Thanks.

I didn't quite understand "as you can do with the current PPA dependencies". What can I currently do with the PPA dependencies? I don't see any way of setting any special options.

I don't see what implications using something from "proposed" would have. We're not talking about a dependency of the finished package here, just something that needs to be on the machine that compiles it. No one using the package will ever even know that linux-libc-dev 2.6.24-19.37 was used. By the time that a few people have started to use my PPA, the chances are that 2.6.24-19.37 will have made it into the main repos anyway.

There is a lot of talk about plans and the way things are done around here, but isn't there documentation? It's always going to feel like I'm running up against the whims of a couple of individuals unless I can consult something which is clearly written down in black and white, *before* I have to file a bug due to my failure. I want to RTFM.

It seemed to me that the proper way to contribute to the community was to use something like Launchpad PPA, but I'll just have to create a repo on my own website if there are too many hurdles here.

[Celso Providelo (cprov)]

On Wed, Jul 23, 2008 at 8:42 PM, ChameleonDave <email address hidden> wrote:
> Thanks.
>
> I didn't quite understand "as you can do with the current PPA
> dependencies". What can I currently do with the PPA dependencies? I
> don't see any way of setting any special options.

Currently you can configure your PPA to use binaries from other PPAs
to build its packages.

Let's say you are building a device driver and you want it to always
build on-top-of the latest kernel available in the
Ubuntu-kernel-developers PPA. Instead of lurking around, finding which
one is the latest kernel version and copying it to your PPA, you can
simple set your PPA to depend on ubuntu-kernel-team PPA.

See launchpad.net/people/+me/+archive/+edit-dependencies

Once it's set the archive dependency(ies) binaries will be used to
build the sources uploaded to your PPA, as expected the highest
version of a requested build dependency (considering the whole set of
archive dependencies) will be installed.

> I don't see what implications using something from "proposed" would
> have. We're not talking about a dependency of the finished package
> here, just something that needs to be on the machine that compiles it.
> No one using the package will ever even know that linux-libc-dev
> 2.6.24-19.37 was used. By the time that a few people have started to
> use my PPA, the chances are that 2.6.24-19.37 will have made it into the
> main repos anyway.

Well, you can't guarantee a build-dependency will *not* affect the
dependencies of the resulted binaries (in fact, it usually does),

Also, in the case it doesn't (you are lucky) you would be shipping
binaries that would require an extra pocket to be enabled in order to
rebuild the package locally.

You can't even be sure that the proposed version will made its way to -updates.

Just to give you an idea, in ubuntu primary archive, only sources
uploaded to proposed pocket itself are able to use build-deps from
proposed, the same goes for backports.

> There is a lot of talk about plans and the way things are done around
> here, but isn't there documentation? It's always going to feel like I'm
> running up against the whims of a couple of individuals unless I can
> consult something which is clearly written down in black and white,
> *before* I have to file a bug due to my failure. I want to RTFM.

Right, the current documentation isn't even close to 'enough' and we
will be working to improve it this next cycle, step-by-step operations
and a enhanced packaging-guide.

Meanwhile, the best place to ask about PPAs is #ubuntu-motu on freenode.

> It seemed to me that the proper way to contribute to the community was
> to use something like Launchpad PPA, but I'll just have to create a repo
> on my own website if there are too many hurdles here.

You don't have to, over one thousand of developers are using PPAs and
while it's not fully functional for 100 % of the cases, we are working
to cover most of them the faster we can.

--
Celso Providelo <email address hidden>
IRC: cprov, Jabber: <email address hidden>, Skype: cprovidelo
1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469

[David D Short (chameleondave)]

Thanks for that.

What dependency would I currently have to add in order to make this one package build (assuming it can be done)?

[TJ (tj)]

I've just incurred this penalty trying to build my modified hal package that supports automatic LUKS key-file use for gnome-mount.

I saw the new hal release in hardy-proposed so pulled in its source, added my patch and updated the version. Uploaded it to the PPA and the i386/amd64 builds failed due to a missing dependency on the latest libsmbios-dev (also updated in hardy-proposed).

It would be *very* useful to be able to allow -proposed for specific package builds since it allows us to test our own modifications against proposed releases and if there are problems, report them before the -proposed package migrates to -updates.

I ended up downloading the libsmbios-dev source from -proposed:

$ apt-get source libsmbiosp-dev -t hardy-proposed

Bumped the version from "0.13.10-1ubuntu1.1" to "0.13.10-1ubuntu1.2~ppa1h" and uploaded the package to my PPA.

Lucky I didn't need to alter the 'depends' in the hal package's debian/control since the binaries are unchanged (hal specifies a depend on "libsmbios-dev(>= 0.13.10-1ubuntu1.1) [i386 amd64]".

[Terence Simpson (tsimpson)]

This appears to be implemented on edge.

[Terence Simpson (tsimpson)]

Dup of Bug #246685 ?