SourcePackageRecipes fail with private branches

It is true that source package recipe builds support only public branches, but "You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See "bzr help launchpad-login"." is a warning, not an error.

Rest of the build log:

http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-servers/ubuntuone-dependencies/ is permanently redirected to https+urllib://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-servers/ubuntuone-dependencies/
bzr: ERROR: Connection error: while sending POST /~ubuntuone-control-tower/ubuntuone-servers/ubuntuone-dependencies/.bzr/smart: [Errno 110] Connection timed out
RUN: /usr/share/launchpad-buildd/slavebin/scan-for-processes ['/usr/share/launchpad-buildd/slavebin/scan-for-processes', '4e883cb3495563a69d962bb40e0f62a5dce96a82']
Scanning for processes to kill in build /home/buildd/build-4e883cb3495563a69d962bb40e0f62a5dce96a82/chroot-autobuild...
RUN: /usr/share/launchpad-buildd/slavebin/umount-chroot ['umount-chroot', '4e883cb3495563a69d962bb40e0f62a5dce96a82']
Unmounting chroot for build 4e883cb3495563a69d962bb40e0f62a5dce96a82...
RUN: /usr/share/launchpad-buildd/slavebin/remove-build ['remove-build', '4e883cb3495563a69d962bb40e0f62a5dce96a82']
Removing build 4e883cb3495563a69d962bb40e0f62a5dce96a82

The expected failure would be bzr: ERROR: Not a branch: "https+urllib://bazaar.launchpad.net/~ubuntuone-control-ower/ubuntuone-servers/ubuntuone-dependencies/".

It's not clear why it's being redirected to https+urllib://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-servers/ubuntuone-dependencies/ or why there is no response to the POST.

<rockstar> bigjools, so, launchpad.View on the recipe is about to land, so that might be the first step towards privacy. What else do we need?
<rockstar> bigjools, I guess the buildds need to be set up to get to private branches, and then we're good, ent?
<bigjools> rockstar: provided you're using a private archive, all will be well
<bigjools> rockstar: however, you will need to make sure any librarian files are in the restricted librarian
<rockstar> bigjools, okay. We'll need some testing here, I guess.
<bigjools> yes :)
<rockstar> bigjools, wouldn't the buildds be responsible for putting files in the right place?
<bigjools> all the privacy is handled in the private PPA for uploaded files
<bigjools> I am just talking about recipe files etc
<bigjools> the buildds are oblivious to privacy
<rockstar> bigjools, okay, we'll have to note that.

Adding a check that you can't build a private recipe in to a public archive
would be good.

Thanks,

James

> Adding a check that you can't build a private recipe in to a public archive
> would be good.

I almost did this. I would absolutely hate for our custom build to land in a
public PPA because we have changes that would break things for others.

Would a restriction on building private recipes to public archives interfere with releasing security fixes via a PPA?

> Would a restriction on building private recipes to public archives
> interfere with releasing security fixes via a PPA?

Probably, what about a check box that displays if you select a private PPA that
says you understand this build will be public. Just enough to make you think
about what you're doing but not enough to really interfere with the process.

I think you mean "if you select a non-private PPA"?

I'm a bit confused about what you mean with "restriction on building private recipes to public archives" means, and the conversation following it.

You're suggesting that private recipes would get built into public archives? Or you're saying to just fail if you try to build a private recipe to a public archive?

Yes, both.

It's not possible to build something that depends on a private branch because
the recipe builder can't access it. At the point, it's also possible to fire
these off for public PPA's.

On the PPA note, I don't see any issue restricting the build to private PPA's
entirely if there is a private branch in the recipe. Mostly because you can
simply copy the data to a public PPA in a few clicks.

I'm not recommending anything. I'm asking whether preventing private recipes from being built into public archives would be a problem, because it would prevent people from releasing security fixes. It seems like it would be a problem.

Re-triaging low because private branches aren't part of our mandate: to support upstreams building packages of their latest code.

I don't see that not being able to build private branches into public PPAs would be an issue. If you're building stuff to public PPAs from private branches, why is there a private branch involved at all? If I have a private branch, it's probably because the project it is for is a private (commercial) project, and I'd rather avoid dumping that code out to the public.

Here's my take on it..

Build the recipe with the private branch into the private PPA
Go to https://launchpad.net/~team/+archive/private-ppa
View package details
Copy packages
Destination PPA: Some Public PPA
Copy options: Copy existing binaries

To me.. that seems very easy. It would make it not a big deal at all to make is
so a recipe with a private branch involved needs to be built in a private PPA.

It would probably make the recipe coders lives much easier too.

Just my opinion. Many smarter guys than me working on it. :)

Rodney, your branch isn't necessarily private because it's for a commercial project. It may be private because it is contains (or may contain) fixes for security vulnerabilities. For example, https://code.edge.launchpad.net/~launchpad-pqm/launchpad/production-devel is private for this reason.

You don't want to make this code available until you have publicly-available packages that provide it. One way of getting publicly-available packages is by building the recipe into a public PPA. (Another is by building to a private PPA and then copying to a public one.)

> Would a restriction on building private recipes to public archives interfere with releasing security fixes via a PPA?

It's moot. Security fixes are always done in a private PPA and the source and binary are unembargoed directly into Ubuntu via a package copy operation.

On Wed, 2010-07-28 at 22:29 +0000, Aaron Bentley wrote:
> Rodney, your branch isn't necessarily private because it's for a
> commercial project. It may be private because it is contains (or may
> contain) fixes for security vulnerabilities. For example,
> https://code.edge.launchpad.net/~launchpad-pqm/launchpad/production-
> devel is private for this reason.
>
> You don't want to make this code available until you have publicly-
> available packages that provide it. One way of getting publicly-
> available packages is by building the recipe into a public PPA.
> (Another is by building to a private PPA and then copying to a public
> one.)

OK. But it looks like Julian's reply from a few hours ago, seems to
suggest this irrelevant to how the security fix builds are done. And I
think even in that case, you probably don't want to build to a public
branch, if you're trying to keep it private.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/30/2010 01:20 PM, Rodney Dawes wrote:
> On Wed, 2010-07-28 at 22:29 +0000, Aaron Bentley wrote:
>> Rodney, your branch isn't necessarily private because it's for a
>> commercial project. It may be private because it is contains (or may
>> contain) fixes for security vulnerabilities. For example,
>> https://code.edge.launchpad.net/~launchpad-pqm/launchpad/production-
>> devel is private for this reason.
>>
>> You don't want to make this code available until you have publicly-
>> available packages that provide it. One way of getting publicly-
>> available packages is by building the recipe into a public PPA.
>> (Another is by building to a private PPA and then copying to a public
>> one.)
>
> OK. But it looks like Julian's reply from a few hours ago, seems to
> suggest this irrelevant to how the security fix builds are done.

Julian described how fixes are done by Ubuntu, but this feature is meant
for upstreams. It's not impossible that they would have a different
workflow. It's much the same as what Michael Lustfield wrote, or indeed
"(Another is by building to a private PPA and then copying to a public
one.)", as I wrote.

> And I
> think even in that case, you probably don't want to build to a public
> branch, if you're trying to keep it private.

I don't understand what that means. Do you mean "public PPA" not
"public branch"? If "that case" means Julian's description, he's not
describing building to a public PPA, so I don't understand what you mean.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTE7gACgkQ0F+nu1YWqI0GOACfRdyhdovB/G32v6Cu2NxPF3vw
UcQAni5xkd2/zR4/i/5MNMZRTlvA6+4S
=M8ql
-----END PGP SIGNATURE-----

I see that Launchpad won't even let me create a recipe for a private branch now. Nor will it let me save an edit to an existing recipe already created for a private branch.

Does this mean this is a "Won't Fix" bug now?

It means we have no plans to fix it. It doesn't mean we think fixing it would be a bad idea.