Can't use 'run' in recipe

We specifically blacklist run for security. This is working as designed.

A workaround that you might want to take is having a branch that you merge do the moving of the files around so that when it's merged, you have a tree that you can package.

nest won't let you nest two sources into the same directory and merge won't let you perform the merge unless they have a common ancestry.

I'm trying to get the source, nest the debian/, then change some parts in debian/ by overwriting them from the other branch.

How can I make a branch move the files as you mentioned?

On Thu, 22 Jul 2010 10:01:28 you wrote:
> We specifically blacklist run for security. This is working as
> designed.
>
> A workaround that you might want to take is having a branch that you
> merge do the moving of the files around so that when it's merged, you
> have a tree that you can package.
>
> ** Changed in: launchpad-code
> Status: New => Invalid

Why are we doing this? Isn't the whole point of running the recipe job in a
secure server is to allow arbitrary code execution?

Tim

I was just curious what makes 'run' different from 'rules'

I just reopened because it sounds like a few others that work on launchpad don't understand why it's blacklisted.

In a sense, run is the same as rules because both allow for arbitrary code execution, and so run is unnecessary.

However, run was blacklisted to ensure that the debianized tree output for a given recipe would be repeatable.

See the "Supporting commands" section of https://wiki.ubuntu.com/DailyUpstreamBuildsPOCSpec.

We are also considering performing the tree generation as a separate step on a non-buildfarm, non-virtualized machine, and that would mean we could not run untrusted code.

There's another use case for run that isn't covered by debian/rules. I have a script in the Samba 4 Debian packages that updates the Build-Depends and Build-Depends-Indep line in debian/control file based on the upstream source tree that was merged in. Since upstream keeps bumping the minimum required version of libraries it is necessary to reflect this in the build dependencies, otherwise my builds fail (and I have to manually adjust by running my script).

It would be nice if recipes created a revision rather than manifest, this would take care of the reproducibility aspect.

By "created a revision", do you mean "committed to the base branch after building the tree"?

I do mean creating a Bazaar revision, but I'm not entirely sure where. The base branch wouldn't always be appropriate, and which snapshot would we commit back there when uploading source packages for multiple distroseries?

Some of my existing recipes are built from branches that I do not have write access to, e.g. because they are vcs imports or mirrors of Debian branches. Perhaps it could be a separate branch that replaces the manifests and lives under the recipe's namespace? Another advantage of this is that it would give us a single revision id that can be used to find back the source trees from a source package control field (a manifest database id would also work but is very Launchpad specific).

Getting back to the original use case, after pondering about this some more over the last couple of weeks, I'm not entirely sure if the "run" command is something that would be appropriate for my use case. The existing scripts that I have that I would like to run using the "run" command are written in Python but have dependencies as well, in my case they depend on bzr and python-debian. Other people will have other dependencies for their scripts, and we have no place to specify them at the moment (these scripts generate the build dependencies so we can't really use those yet).

Adding a way to specify recipe build dependencies seems like the wrong thing to do. It means we'd have recipe dependencies, build dependencies and binary package dependencies, and that would make the whole process more complex and more confusing to understand for new users. Perhaps we can add something more specific to this use case instead of the generic "run" command ? Or perhaps we should offer users a limited set of packages they can use in the run script and hope that is sufficient for their needs? I'm not sure.

FWIW The files that I would want to update while building the source package would always be under debian/. I don't think there is a good use case for changing the upstream source code.

I've just filed bug 685571 about updating the version string.

So are we happy to leave this invalid (or maybe more accurately 'wontfix') or is more discussion needed of whether 'run' could ever be supported?

The problem is, I want to be able to nest-part a folder into the ROOT of the branch. In other words, copy files right to the root instead of into a directory off of the root. Here is my recipe:

# bzr-builder format 0.3 deb-version {debupstream}+{revno}
lp:~snapcpp/snapcpp/snapCMakeModules
nest-part modules lp:snapcpp snapCMakeModules snapCMakeModules
run cp -aux snapCMakeModules/* .

branch "lp:~snapcpp/snapcpp/snapCMakeModules" is empty. I nest-part just snapCMakeModules into my empty branch, then copy the files into the root with the run command.

If nest-part would support the following:
   nest-part modules lp:snapcpp snapCMakeModules .
then I wouldn't need the run command. Ugh.

Maybe you could write a patch to make nest-part do what you need?

On 5 December 2013 13:40, Doug Barbieri <email address hidden> wrote:
> The problem is, I want to be able to nest-part a folder into the ROOT of
> the branch. In other words, copy files right to the root instead of into
> a directory off of the root. Here is my recipe:
>
> # bzr-builder format 0.3 deb-version {debupstream}+{revno}
> lp:~snapcpp/snapcpp/snapCMakeModules
> nest-part modules lp:snapcpp snapCMakeModules snapCMakeModules
> run cp -aux snapCMakeModules/* .
>
> branch "lp:~snapcpp/snapcpp/snapCMakeModules" is empty. I nest-part just
> snapCMakeModules into my empty branch, then copy the files into the root
> with the run command.
>
> If nest-part would support the following:
> nest-part modules lp:snapcpp snapCMakeModules .
> then I wouldn't need the run command. Ugh.
>
> --
> You received this bug notification because you are subscribed to
> Launchpad Suite.
> https://bugs.launchpad.net/bugs/608450
>
> Title:
> Can't use 'run' in recipe
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/launchpad/+bug/608450/+subscriptions

--
Robert Collins <email address hidden>
Distinguished Technologist
HP Converged Cloud