Commit 89606032d2741d765ebfa44d483458d45d98548d - rust-fixedbitset

close cargo bug and update README for multi-packaging workflow Ximin Luo 4 years ago

2 changed file(s) with 85 addition(s) and 41 deletion(s). Raw diff Collapse all Expand all

+84

-41

README.rst less more

0		Instructions
1		============
	0	.. contents::
	1
	2	Packaging a crate for Debian
	3	============================
2	4
3	5	To get set up, run::
4	6

70	72	used previously. This version is mentioned in ``debian/changelog``.
71	73
72	74
	75	Build environment
	76	=================
	77
	78	To set up a suitable build environment for ``./build.sh``::
	79
	80	$ sudo apt-get install devscripts reprepro debootstrap sbuild dh-cargo schroot autopkgtest
	81	$ sudo sbuild-createchroot --include=eatmydata,ccache,gnupg,dh-cargo,cargo,lintian,perl-openssl-defaults \
	82	--chroot-prefix debcargo-unstable unstable \
	83	/srv/chroot/debcargo-unstable-amd64-sbuild http://deb.debian.org/debian
	84
	85	An explanation of this, plus more recipes, can be found on the `sbuild wiki
	86	page <https://wiki.debian.org/sbuild>`_.
	87
	88	Normally, ``./build.sh`` will fail early if not all the build dependencies are
	89	available in your local apt cache. If you are packaging a large dependency tree
	90	however, to avoid many round-trips through NEW it is possible to bypass this
	91	check and build all the packages together. Suppose package B depends on package
	92	A, then you can run something like::
	93
	94	$ export IGNORE_MISSING_BUILD_DEPS=1
	95	$ ./release.sh A
	96	$ ( cd build && ./build.sh A )
	97	# push pending and checkout master
	98	$ ./release.sh B
	99	$ ( cd build && ./build.sh B librust-A*.deb )
	100
	101	The extra arguments after ``./build.sh B <args>`` is extra deb files to pass to
	102	sbuild to use as dependencies. In this case, ``librust-A*.deb`` should have
	103	been built by the previous step.
	104
	105	After everything is built successfully, you can ``dput`` all of them and then
	106	push all the ``pending-*`` branches as normal.
	107
	108
73	109	Repository structure
74	110	====================
75	111
76		`pending-*` branches are managed by `./release.sh`, so please don't manage them
77		yourself as you will interfere with the working of that script. The intention
78		is that they should only differ from the master branch by 1 commit, i.e. the
79		`dch -r` commit created by `./release.sh`.
	112	``pending-*`` branches are managed by ``./release.sh``, so please don't manage
	113	them yourself as you will interfere with the working of that script. The
	114	intention is that they should only differ from the master branch by 1 commit,
	115	i.e. the ``dch -r`` commit created by ``./release.sh``.
80	116
81	117	If you want to create separate non-master branches, that is fine - just don't
82		call them `pending-*` and don't run `./release.sh` on those branches. If you
	118	call them ``pending-*`` and don't run ``./release.sh`` on those branches. If you
83	119	want to test your crate, instead run::
84	120
85	121	cd build && [SOURCEONLY=1] ./build.sh <rust-crate-name> [<old-version>]

98	134	merge commit.
99	135
100	136
101		Build environment
102		=================
103
104		To set up a suitable build environment for ``./build.sh``::
105
106		$ sudo apt-get install devscripts reprepro debootstrap sbuild dh-cargo schroot autopkgtest
107		$ sudo sbuild-createchroot --include=eatmydata,ccache,gnupg,dh-cargo,cargo,lintian,perl-openssl-defaults \
108		--chroot-prefix debcargo-unstable unstable \
109		/srv/chroot/debcargo-unstable-amd64-sbuild http://deb.debian.org/debian
110
111		An explanation of this, plus more recipes, can be found on the `sbuild wiki
112		page <https://wiki.debian.org/sbuild>`_.
113
114		Normally, ``./build.sh`` will fail early if not all the build dependencies are
115		available in your local apt cache. If you are packaging a large dependency tree
116		however, to avoid many round-trips through NEW it is possible to bypass this
117		check and build all the packages together. Suppose package B depends on package
118		A, then you can run something like::
119
120		$ export IGNORE_MISSING_BUILD_DEPS=1
121		$ ./release.sh A
122		$ ( cd build && ./build.sh A )
123		# push pending and checkout master
124		$ ./release.sh B
125		$ ( cd build && ./build.sh B librust-A*.deb )
126
127		The extra arguments after ``./build.sh B <args>`` is extra deb files to pass to
128		sbuild to use as dependencies. In this case, ``librust-A*.deb`` should have
129		been built by the previous step.
130
131		After everything is built successfully, you can ``dput`` all of them and then
132		push all the ``pending-*`` branches as normal.
	137	Expert mode & packaging multiple packages
	138	=========================================
	139
	140	You should get used to the single-packaging workflow a bit first, including
	141	doing a few `test builds <#build-environment>`_ of your package. Otherwise the
	142	instructions below may seem a bit opaque.
	143
	144	1. ``rm -rf build/* && sbuild-update -udr debcargo-unstable-amd64-sbuild`` -
	145	clears out your build directory, making the subsequent steps a bit faster.
	146	2. ``./update.sh <CRATE>`` for all your relevant packages
	147	3. Do any manual updates.
	148	4. ``cd build` then ``IGNORE_MISSING_BUILD_DEPS=1 ./build.sh <CRATE> *.deb``
	149	for all your relevant packages, in dependency order.
	150	5. Deal with any issues that come up.
	151	6. Push your updates to our git.
	152	7. Run ``dev/list-rdeps <CRATE> [<CRATE> ...]`` on all the crates you updated.
	153	Any reverse-dependencies that are affected, also need to be updated and you
	154	should repeat steps 1-7 (including this step) for them as well, until this
	155	step lists no new packages that are affected.
	156	8. ``./release.sh <CRATE>`` for all the packages you updated, running the build
	157	again if necessary. It may be possible to do this out of dependency order,
	158	assuming you didn't have to make significant changes in step (5). If you
	159	did, then this step also has to be done in dependency order.
	160	9. Push your ``pending-*`` branches to our git.
	161
	162	I like to have 4 shell windows open for this:
	163
	164	1. To do the manual updates.
	165	2. To explore git, to remember what step you're on and to lookup previous
	166	reference material.
	167	3. To explore the build directory, e.g. logs and crate source code.
	168	4. To run a build. Try to have one running in the background at all times, for
	169	the next package you didn't look at yet, to save time waiting.
	170
	171	There are also various scripts in ``dev/*`` that might help you. They should
	172	have a couple lines at the top of the source code describing their
	173	functionality and some brief usage instructions.
	174
	175	Whew, thanks for all your work!
133	176
134	177
135	178	General packaging tips

142	185	crates only use clippy to lint themselves and it is not a "real" dependency
143	186	in the sense that they actually import clippy's code for what they do.
144	187
145		If you want to be sure, `rg clippy` and check that all the usages of it are
146		inside `cfg_attr` declarations. If so, then just get rid of it.
	188	If you want to be sure, ``rg clippy`` and check that all the usages of it are
	189	inside ``cfg_attr`` declarations. If so, then just get rid of it.
147	190
148	191	OS-specific crates
149	192	------------------

-0

src/cargo/debian/changelog less more

0	0	rust-cargo (0.43.1-1) UNRELEASED-FIXME-AUTOGENERATED-DEBCARGO; urgency=medium
1	1
2	2	* Package cargo 0.43.1 from crates.io using debcargo 2.4.2
	3	* Closes: #955638
3	4
4	5	-- Ximin Luo <infinity0@debian.org> Sat, 18 Apr 2020 14:47:30 +0100
5	6