Create Launchpad PPAs for stable and daily builds #2131

New Issue

tahoe-lafs · 2013-12-06T14:16:58Z

amontero commented

2013-12-06 14:16:58 +00:00

Having a daily built development PPA on Launchpad would ease testing of latest code. Adding a PPA is one of the easiest ways for users to access packages outside their distros and lowering this barrier as much as possible can help attract more testers. Read more on why at https://help.launchpad.net/Packaging/SourceBuilds.

The way to accomplish this is using Launchpad's "packaging recipes" and code imports from the appropiate branches at Github. LP provides a buildbot facility to ease and even automate this.

This could also be used to create derivate or experimental builds such as I2P packages, for instance.

"Taho-LAFS Team" at Launchpad page is already set up at:
https://launchpad.net/~tahoe-lafs

Having a daily built development PPA on Launchpad would ease testing of latest code. Adding a PPA is one of the easiest ways for users to access packages outside their distros and lowering this barrier as much as possible can help attract more testers. Read more on why at <https://help.launchpad.net/Packaging/SourceBuilds>. The way to accomplish this is using Launchpad's "packaging recipes" and code imports from the appropiate branches at Github. LP provides a buildbot facility to ease and even automate this. This could also be used to create derivate or experimental builds such as I2P packages, for instance. "Taho-LAFS Team" at Launchpad page is already set up at: <https://launchpad.net/~tahoe-lafs>

tahoe-lafs added the

labels 2013-12-06 14:16:58 +00:00

tahoe-lafs added this to the undecided milestone 2013-12-06 14:16:58 +00:00

tahoe-lafs added

packaging

and removed

unknown

labels 2013-12-06 14:31:57 +00:00

daira commented

2013-12-06 15:03:14 +00:00

+1

tahoe-lafs modified the milestone from undecided to soon

2013-12-06 15:03:54 +00:00

amontero commented

2013-12-06 16:46:48 +00:00

Applied as Tahoe-LAFS LP team member.
Someone there with admin access should add a link in the LP team page description to this ticket to keep everyone on the same page.

Applied as Tahoe-LAFS LP team member. Someone there with admin access should add a link in the LP team page description to this ticket to keep everyone on the same page.

zooko commented

2013-12-07 15:27:16 +00:00

Replying to amontero:

Applied as Tahoe-LAFS LP team member.
Someone there with admin access should add a link in the LP team page description to this ticket to keep everyone on the same page.

Done: https://launchpad.net/~tahoe-lafs

Replying to [amontero](/tahoe-lafs/trac-2024-07-25/issues/2131#issuecomment-94182): > Applied as Tahoe-LAFS LP team member. > Someone there with admin access should add a link in the LP team page description to this ticket to keep everyone on the same page. Done: <https://launchpad.net/~tahoe-lafs>

amontero commented

2013-12-11 16:41:13 +00:00

When asking on IRC for how to differentiate builds from the WebUIs using specific version strings, Zooko pointed to related Versioneer issue: https://github.com/warner/python-versioneer/issues/6
Also, Zooko's solution (copied verbatim):

echo "!appname! = 'amonteros-experiment'" >> src/allmydata/_appname.py

Daira suggested to append .dev0 to the version string instead of doing it with !appname! to avoid incompatibilities in the files created in node directories.
Daira's solution is editing/creating src/allmydata/_version.py . If it is not present, a build from a git checkout will generate it.

Alternatively, have the bzr import run 'python setup.py verinfo' (iirc) on the git tree before doing the incremental import.

When asking on IRC for how to differentiate builds from the WebUIs using specific version strings, Zooko pointed to related Versioneer issue: <https://github.com/warner/python-versioneer/issues/6> Also, Zooko's solution (copied verbatim): echo "!*appname!* = 'amonteros-experiment'" >> src/allmydata/_appname.py Daira suggested to append .dev0 to the version string instead of doing it with !*appname!* to avoid incompatibilities in the files created in node directories. Daira's solution is editing/creating src/allmydata/_version.py . If it is not present, a build from a git checkout will generate it. > Alternatively, have the bzr import run 'python setup.py verinfo' (iirc) on the git tree before doing the incremental import.

zooko commented

2013-12-12 04:56:51 +00:00

Replying to amontero:

Also, Zooko's solution (copied verbatim):

echo "!appname! = 'amonteros-experiment'" >> src/allmydata/_appname.py

Daira suggested to append .dev0 to the version string instead of doing it with !appname! to avoid incompatibilities in the files created in node directories.

You might want files created in node directories (i.e. tahoe-client.tac) to be incompatible! Maybe you want node directories created with your amonteros-experiment branch to fail if you try to start that node using the mainline. Or maybe not! But I also don't think it is that big of a deal either way. By the way, #1159 would make it so that the node directories can be started by tahoe code regardless of its appname.

Replying to [amontero](/tahoe-lafs/trac-2024-07-25/issues/2131#issuecomment-94184): > Also, Zooko's solution (copied verbatim): > > echo "!*appname!* = 'amonteros-experiment'" >> src/allmydata/_appname.py > > Daira suggested to append .dev0 to the version string instead of doing it with !*appname!* to avoid incompatibilities in the files created in node directories. You might *want* files created in node directories (i.e. `tahoe-client.tac`) to be incompatible! Maybe you want node directories created with your amonteros-experiment branch to fail if you try to start that node using the mainline. Or maybe not! But I also don't think it is that big of a deal either way. By the way, #1159 would make it so that the node directories can be started by tahoe code regardless of its appname.

daira commented

2013-12-12 15:54:19 +00:00

Replying to [zooko]comment:8:

You might want files created in node directories (i.e. tahoe-client.tac) to be incompatible!

Why? Then your node directories would fail even if your branch were merged into the mainline. I do think this is a big deal, because it's an unnecessary support hassle.

Replying to [zooko]comment:8: > You might *want* files created in node directories (i.e. `tahoe-client.tac`) to be incompatible! Why? Then your node directories would fail even if your branch were merged into the mainline. I do think this is a big deal, because it's an unnecessary support hassle.

zooko commented

2013-12-17 21:28:35 +00:00

Replying to [daira]comment:9:

Replying to [zooko]comment:8:

You might want files created in node directories (i.e. tahoe-client.tac) to be incompatible!

Why? Then your node directories would fail even if your branch were merged into the mainline. I do think this is a big deal, because it's an unnecessary support hassle.

You might want a guarantee that nodes created with your branch will never get run by trunk. So that you could experiment with incompatible changes. Or maybe not. I don't think it is a big deal, but obviously I should go fix #1159 so that we can stop talking about this and get onto bigger things!

Replying to [daira]comment:9: > Replying to [zooko]comment:8: > > You might *want* files created in node directories (i.e. `tahoe-client.tac`) to be incompatible! > > Why? Then your node directories would fail even if your branch were merged into the mainline. I do think this is a big deal, because it's an unnecessary support hassle. You might want a guarantee that nodes created with your branch will never get run by trunk. So that you could experiment with incompatible changes. Or maybe not. I don't think it is a big deal, but obviously I should go fix #1159 so that we can stop talking about this and get onto bigger things!

Sign in to join this conversation.