alibuild 1.17.19__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- alibuild-1.17.19.data/scripts/aliBuild +137 -0
- alibuild-1.17.19.data/scripts/aliDeps +7 -0
- alibuild-1.17.19.data/scripts/aliDoctor +7 -0
- alibuild-1.17.19.data/scripts/alienv +344 -0
- alibuild-1.17.19.data/scripts/pb +7 -0
- alibuild-1.17.19.dist-info/METADATA +78 -0
- alibuild-1.17.19.dist-info/RECORD +74 -0
- alibuild-1.17.19.dist-info/WHEEL +5 -0
- alibuild-1.17.19.dist-info/licenses/LICENSE.md +674 -0
- alibuild-1.17.19.dist-info/top_level.txt +5 -0
- alibuild_helpers/__init__.py +21 -0
- alibuild_helpers/_version.py +21 -0
- alibuild_helpers/analytics.py +120 -0
- alibuild_helpers/args.py +493 -0
- alibuild_helpers/build.py +1209 -0
- alibuild_helpers/build_template.sh +314 -0
- alibuild_helpers/clean.py +83 -0
- alibuild_helpers/cmd.py +154 -0
- alibuild_helpers/deps.py +116 -0
- alibuild_helpers/doctor.py +195 -0
- alibuild_helpers/git.py +104 -0
- alibuild_helpers/init.py +103 -0
- alibuild_helpers/log.py +132 -0
- alibuild_helpers/scm.py +31 -0
- alibuild_helpers/sl.py +62 -0
- alibuild_helpers/sync.py +693 -0
- alibuild_helpers/templating_plugin.py +18 -0
- alibuild_helpers/utilities.py +662 -0
- alibuild_helpers/workarea.py +179 -0
- debian/changelog +11 -0
- debian/compat +1 -0
- debian/control +14 -0
- debian/copyright +10 -0
- debian/files +1 -0
- debian/rules +7 -0
- docs/README.md +1 -0
- docs/SUPPORT +3 -0
- docs/docs/alice_logo.png +0 -0
- docs/docs/deps.png +0 -0
- docs/docs/index.md +75 -0
- docs/docs/quick.md +89 -0
- docs/docs/reference.md +430 -0
- docs/docs/stylesheets/extra.css +9 -0
- docs/docs/troubleshooting.md +346 -0
- docs/docs/user.md +413 -0
- docs/mkdocs.yml +37 -0
- templates/alibuild_to_please.jnj +63 -0
- tests/test_analytics.py +42 -0
- tests/test_args.py +119 -0
- tests/test_build.py +426 -0
- tests/test_clean.py +154 -0
- tests/test_cmd.py +73 -0
- tests/test_deps.py +79 -0
- tests/test_doctor.py +128 -0
- tests/test_git.py +48 -0
- tests/test_hashing.py +67 -0
- tests/test_init.py +103 -0
- tests/test_log.py +50 -0
- tests/test_packagelist.py +235 -0
- tests/test_parseRecipe.py +132 -0
- tests/test_sync.py +332 -0
- tests/test_utilities.py +383 -0
- tests/test_workarea.py +101 -0
- tests/testdist/broken1.sh +1 -0
- tests/testdist/broken2.sh +1 -0
- tests/testdist/broken3.sh +3 -0
- tests/testdist/broken4.sh +2 -0
- tests/testdist/broken5.sh +2 -0
- tests/testdist/broken6.sh +2 -0
- tests/testdist/broken7.sh +5 -0
- tests/testdist/clobber-initdotsh.sh +4 -0
- tests/testdist/defaults-o2.sh +10 -0
- tests/testdist/delete-etc.sh +4 -0
- tests/testdist/tracking-env.sh +6 -0
|
@@ -0,0 +1,346 @@
|
|
|
1
|
+
---
|
|
2
|
+
subtitle: Troubleshooting
|
|
3
|
+
layout: main
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
In case build fails you can find per-build log files under the `BUILD` directory
|
|
7
|
+
located in the working directory.
|
|
8
|
+
|
|
9
|
+
Assuming the working directory is `sw` (the default) and the package whose
|
|
10
|
+
build failed is `boost`, you will find its log under:
|
|
11
|
+
|
|
12
|
+
sw/BUILD/boost-latest/log
|
|
13
|
+
|
|
14
|
+
Note that when running `aliBuild --debug` the output is also echoed in your
|
|
15
|
+
current terminal.
|
|
16
|
+
|
|
17
|
+
## Common issues
|
|
18
|
+
|
|
19
|
+
### I have an error while compiling AliPhysics / AliRoot.
|
|
20
|
+
|
|
21
|
+
Notice that in general this kind of errors are not really aliBuild
|
|
22
|
+
related, but they are genuine issues in either AliRoot and AliPhysics.
|
|
23
|
+
To get the accurate and fastest feedback, the "best practice" is to do
|
|
24
|
+
the following:
|
|
25
|
+
|
|
26
|
+
- Make sure you have the latest version of both AliPhysics **and** AliRoot. If
|
|
27
|
+
not, update to it and rebuild. Most likely someone else has already noticed
|
|
28
|
+
your problem and fixed it. aliBuild will actually remind you of doing so if
|
|
29
|
+
you are using master.
|
|
30
|
+
- If you still have a message, read what the error log for your package
|
|
31
|
+
is saying and try to extract the first error. In general you can simply
|
|
32
|
+
look for the first occurrence of `***` or `error:` and try to read a few
|
|
33
|
+
lines around there.
|
|
34
|
+
- Try to find out who modified the files with an error last. This can be done by
|
|
35
|
+
cd-ing into `AliRoot` / `AliPhysics`, issuing:
|
|
36
|
+
|
|
37
|
+
git log @{yesterday}.. -- <name-of-the-file-with-error>
|
|
38
|
+
|
|
39
|
+
and reading who was the author of the last few commits.
|
|
40
|
+
- Write a message to `alice-project-analysis-task-force@cern.ch`
|
|
41
|
+
explaining the error. Make sure you report the first few lines of it you
|
|
42
|
+
have identified above, and to include the author of the last changes in
|
|
43
|
+
the problematic file.
|
|
44
|
+
- Make sure you do **not** attach big log files since they will cause a
|
|
45
|
+
traffic storm since the list has many participants and each one of them
|
|
46
|
+
will get a copy of the attachment, even if not interested. A much better
|
|
47
|
+
approach is to use a service like [CERNBox](https://cernbox.cern.ch),
|
|
48
|
+
Dropbox or alikes which allow to share files by providing a link to them,
|
|
49
|
+
rather than by attachment.
|
|
50
|
+
|
|
51
|
+
### What are the system prerequisites of alibuild?
|
|
52
|
+
|
|
53
|
+
In principle aliBuild should now notify you for missing required system
|
|
54
|
+
dependencies and complain with a clear message if that is not the case. For
|
|
55
|
+
example if you lack bz2 it will now tell you with the following message:
|
|
56
|
+
|
|
57
|
+
Please install bzip2 development package on your system
|
|
58
|
+
|
|
59
|
+
Moreover it will try to reuse as much as possible from your system, so
|
|
60
|
+
if you have a system CMake which is compatible with the one required by
|
|
61
|
+
AliRoot it will also pick up your version. Failing that it will build it
|
|
62
|
+
for you. You can have a look at what AliRoot will do by adding the `--dry-run`
|
|
63
|
+
option to your build command, e.g.:
|
|
64
|
+
|
|
65
|
+
alibuild --dry-run <additional options you might have> build AliRoot
|
|
66
|
+
|
|
67
|
+
will tell you something like:
|
|
68
|
+
|
|
69
|
+
Using package CMake from the system as preferred choice.
|
|
70
|
+
Using package libxml2 from the system as preferred choice.
|
|
71
|
+
Using package SWIG from the system as preferred choice.
|
|
72
|
+
Using package zlib from the system as preferred choice.
|
|
73
|
+
Using package autotools from the system as preferred choice.
|
|
74
|
+
Using package GSL from the system as preferred choice.
|
|
75
|
+
System package boost cannot be used. Building our own copy.
|
|
76
|
+
We will build packages in the following order: defaults-release AliEn-CAs GMP UUID gSOAP ApMon-CPP GEANT4 boost MPFR MonALISA-gSOAP-client cgal XRootD fastjet xalienfs AliEn-Runtime ROOT vgm GEANT3 GEANT4_VMC AliRoot
|
|
77
|
+
|
|
78
|
+
If you have a system package which you think should be used but it's not, you
|
|
79
|
+
can run `aliDoctor <package-name>` to try to understand why that was the case
|
|
80
|
+
(or you can [open a bug report](https://github.com/alisw/alidist/issues) with its output and we will look at it).
|
|
81
|
+
|
|
82
|
+
### What is PIP ? How do I install it?
|
|
83
|
+
|
|
84
|
+
[PIP](https://pip.pypa.io/en/stable/) is the de-facto standard package manager
|
|
85
|
+
for python. While it is usually installed by default on modern distributions,
|
|
86
|
+
it can happen this is not the case. If so, you can usually get it via:
|
|
87
|
+
|
|
88
|
+
sudo yum install python-pip # (Centos / Fedora / SLC derivatives)
|
|
89
|
+
sudo dnf install python-pip # (Fedora 22+)
|
|
90
|
+
sudo apt-get install python-pip # (Ubuntu / Debian alikes)
|
|
91
|
+
|
|
92
|
+
Alternatively you can try to install it by hand by following the [instructions
|
|
93
|
+
here](https://pip.pypa.io/en/stable/installation/#supported-methods).
|
|
94
|
+
|
|
95
|
+
### Package branch was updated, but aliBuild does not rebuild it
|
|
96
|
+
|
|
97
|
+
Some recipes specify branches in the `tag:` field instead of an actual tag. For
|
|
98
|
+
such recipes, aliBuild must contact remote servers in order to determine what is
|
|
99
|
+
the latest commit for that branch. Since this is a corner case and the operation
|
|
100
|
+
is expensive and slow, it is off by default, and cached information is used
|
|
101
|
+
instead. Try to ask aliBuild to update its cached information by using the `-u`
|
|
102
|
+
or `--fetch-repos` switch.
|
|
103
|
+
|
|
104
|
+
|
|
105
|
+
### AliEn broken after building with aliBuild
|
|
106
|
+
|
|
107
|
+
If you are migrating from other ALICE build instructions to use aliBuild
|
|
108
|
+
and you are running on OSX, it could happen that you encounter an error
|
|
109
|
+
of the kind:
|
|
110
|
+
|
|
111
|
+
```bash
|
|
112
|
+
dlopen error: dlopen(/Users/me/alice/sw/osx_x86-64/ROOT/v5-34-30-alice-1/lib/libNetx.so, 9): Library not loaded: libXrdUtils.1.dylib
|
|
113
|
+
Referenced from: /Users/me/alice/sw/osx_x86-64/ROOT/v5-34-30-alice-1/lib/libNetx.so
|
|
114
|
+
Reason: image not found
|
|
115
|
+
Load Error: Failed to load Dynamic link library /Users/me/alice/sw/osx_x86-64/ROOT/v5-34-30-alice-1/lib/libNetx.so
|
|
116
|
+
E-TCint::AutoLoadCallback: failure loading dependent library libNetx.so for class TAlienJDL
|
|
117
|
+
dlopen error: dlopen(/Users/me/alice/sw/osx_x86-64/ROOT/v5-34-30-alice-1/lib/libRAliEn.so, 9): Library not loaded: /Users/jmargutti/alice/sw/INSTALLROOT/ac18e6eaa3ed801ac1cd1e788ac08c82ffd29235/osx_x86-64/xalienfs/v1.0.14r1-1/lib/libgapiUI.4.so
|
|
118
|
+
Referenced from: /Users/me/alice/sw/osx_x86-64/ROOT/v5-34-30-alice-1/lib/libRAliEn.so
|
|
119
|
+
Reason: image not found
|
|
120
|
+
Load Error: Failed to load Dynamic link library /Users/me/alice/sw/osx_x86-64/ROOT/v5-34-30-alice-1/lib/libRAliEn.so
|
|
121
|
+
E-TCint::AutoLoadCallback: failure loading library libRAliEn.so for class TAlienJDL
|
|
122
|
+
dlopen error: dlopen(/Users/me/alice/sw/osx_x86-64/AliEn-Runtime/v2-19-le-1/lib/libgapiUI.so, 9): Library not loaded: libXrdSec.0.dylib
|
|
123
|
+
Referenced from: /Users/me/alice/sw/osx_x86-64/AliEn-Runtime/v2-19-le-1/lib/libgapiUI.so
|
|
124
|
+
Reason: image not found
|
|
125
|
+
Load Error: Failed to load Dynamic link library /Users/me/alice/sw/osx_x86-64/AliEn-Runtime/v2-19-le-1/lib/libgapiUI.so
|
|
126
|
+
E-P010_TAlien: Please fix your loader path environment variable to be able to load libRAliEn.so
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
This happens because the new version of AliEn compiled by aliBuild is
|
|
130
|
+
incompatible with the old one. You can fix this issue by doing:
|
|
131
|
+
|
|
132
|
+
1. Remove old alien token stuff from `/tmp` (e.g. `rm /tmp/gclient_env* /tmp/gclient_token* /tmp/x509*`)
|
|
133
|
+
2. Get a new token
|
|
134
|
+
3. Source `/tmp/gclient_env*` file
|
|
135
|
+
|
|
136
|
+
|
|
137
|
+
and trying again.
|
|
138
|
+
|
|
139
|
+
### aliBuild does not work on OSX with Python shipped with ANACONDA
|
|
140
|
+
|
|
141
|
+
If you are using ANACONDA (`which python` to verify), the old version of
|
|
142
|
+
aliBuild had troubles with it. Upgrading to the latest version via:
|
|
143
|
+
|
|
144
|
+
pip install --upgrade alibuild
|
|
145
|
+
|
|
146
|
+
or by doing `git pull` should fix the issue.
|
|
147
|
+
|
|
148
|
+
|
|
149
|
+
### aliBuild does not pick up tool X from the system
|
|
150
|
+
|
|
151
|
+
By default aliBuild prefers using tools from the system whenever
|
|
152
|
+
possible. Examples of those tools are CMake, the GCC compiler or the
|
|
153
|
+
autotools suite. If this does not happen even if you have it installed
|
|
154
|
+
it means that aliBuild does not consider you system tool good enough to
|
|
155
|
+
be compatible with the one provided by the recipe. You can verify what
|
|
156
|
+
happens during the system tool detection by running:
|
|
157
|
+
|
|
158
|
+
aliDoctor <package name>
|
|
159
|
+
|
|
160
|
+
|
|
161
|
+
### AliBuild fails with `cannot open file "AvailabilityMacros.h`
|
|
162
|
+
|
|
163
|
+
If your build fails with:
|
|
164
|
+
|
|
165
|
+
```
|
|
166
|
+
Error: cannot open file "AvailabilityMacros.h" sw/BUILD/.../ROOT/include/RConfig.h:384:
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
and you are on macOS, this most likely means you have an incomplete XCode installation,
|
|
170
|
+
e.g. due to an upgrade. You can fix this with:
|
|
171
|
+
|
|
172
|
+
```
|
|
173
|
+
xcode-select --install
|
|
174
|
+
```
|
|
175
|
+
|
|
176
|
+
### I do not have privileges and I cannot install via pip
|
|
177
|
+
|
|
178
|
+
If you do not have root privileges on your machine and `pip install alibuild`
|
|
179
|
+
fails, you have two options:
|
|
180
|
+
|
|
181
|
+
- If your pip supports it, you can add the `--user` flag and that will install
|
|
182
|
+
alibuild in `~/.local`. I.e.:
|
|
183
|
+
|
|
184
|
+
pip install --user alibuild
|
|
185
|
+
|
|
186
|
+
- If your pip is old or if you do not have pip at all on your system or
|
|
187
|
+
you do not want to use pip for whatever reasons, you can still simply
|
|
188
|
+
checkout the sources with:
|
|
189
|
+
|
|
190
|
+
git clone https://github.com/alisw/alibuild
|
|
191
|
+
|
|
192
|
+
and simply run alibuild by invoking `alibuild/aliBuild`.
|
|
193
|
+
|
|
194
|
+
### I am changing an uncommitted file in a development package, but it is not updated in the installation folder.
|
|
195
|
+
|
|
196
|
+
If you add a file to a development package and the build recipe is
|
|
197
|
+
able to handle uncommitted files, it will be copied the first time.
|
|
198
|
+
|
|
199
|
+
However alibuild considers any untracked file as the same, and therefore unless
|
|
200
|
+
the file is added or committed to the local clone of the development package any
|
|
201
|
+
subsequent rebuild will ignore the changes. This can be worked around in two ways:
|
|
202
|
+
|
|
203
|
+
1. You add the file to your local clone via git add / git commit
|
|
204
|
+
2. You add an incremental_recipe which is able to handle uncommitted files
|
|
205
|
+
|
|
206
|
+
What 1. does is to make alibuild aware of the changes of the new file, so you
|
|
207
|
+
will get a new build for each change to the file. What 2. does is to always
|
|
208
|
+
execute the incremental recipe to refresh the installation folder on each aliBuild
|
|
209
|
+
invocation, possibly updating untracked files if so specified in the recipe itself.
|
|
210
|
+
|
|
211
|
+
### How do I set compilation options for AliRoot and / or AliPhysics?
|
|
212
|
+
|
|
213
|
+
If you want to change the compilation options for AliRoot, AliPhysics,
|
|
214
|
+
or as a matter of fact any packages you have two options:
|
|
215
|
+
|
|
216
|
+
- If the package itself is one which you are developing locally, i.e.
|
|
217
|
+
you have the checkout available, you can modify its CMakeFile, add
|
|
218
|
+
whatever options you like there and then issue again your aliBuild
|
|
219
|
+
command.
|
|
220
|
+
- On contrary, if you do not have a local checkout but you still want to
|
|
221
|
+
modify it's compiler flags, you can edit the `alidist/aliroot.sh` recipe
|
|
222
|
+
and add the options there.
|
|
223
|
+
|
|
224
|
+
Finally, for certain common options, e.g. debug flags, we provide a
|
|
225
|
+
precooked configuration using so called [defaults](user.md#defaults).
|
|
226
|
+
Simply add `--defaults debug` to your aliBuild flags and it will add
|
|
227
|
+
debug flags to all your packages.
|
|
228
|
+
|
|
229
|
+
### AliPhysics takes very long time to build and builds things like autotools, GCC
|
|
230
|
+
|
|
231
|
+
In order to build AliPhysics, a number of externals are required,
|
|
232
|
+
including working autotools, boost, and GCC. While aliBuild tries it
|
|
233
|
+
best to reuse whatever comes from the system, it will not complain when
|
|
234
|
+
building unless one of the system dependencies is absolutely required
|
|
235
|
+
(e.g. X11, perl). This might lead to the fact it will rebuild large
|
|
236
|
+
tool, where simply installing them might be a better option. For this
|
|
237
|
+
reason we suggest that users run:
|
|
238
|
+
|
|
239
|
+
aliDoctor AliPhysics
|
|
240
|
+
|
|
241
|
+
in the same path where their `alidist` folder is, before actually
|
|
242
|
+
starting to build, so that they can get an overview of what will be
|
|
243
|
+
picked up from the system and what not.
|
|
244
|
+
|
|
245
|
+
Notice that if you change (either add or remove) your set of system
|
|
246
|
+
dependencies, aliBuild will trigger a rebuild of whatever depends on
|
|
247
|
+
them, taking additional time, so make sure you do this when not pressed
|
|
248
|
+
for a deadline.
|
|
249
|
+
|
|
250
|
+
### Permission denied when running alienv on shared (farm) installations
|
|
251
|
+
|
|
252
|
+
When attempting to do `alienv` operations on shared (farm) installations you
|
|
253
|
+
might get a number of `Permission denied` errors. In order to fix this problem
|
|
254
|
+
you need to make sure that shared builds with `aliBuild` are always made by the
|
|
255
|
+
same user. In addition after every `aliBuild` run the person who has run it has
|
|
256
|
+
to run the following command in order to generate all the correct modulefiles
|
|
257
|
+
as seen by the users:
|
|
258
|
+
|
|
259
|
+
alienv q
|
|
260
|
+
|
|
261
|
+
Users have to append the `--no-refresh` option to every `alienv` operation, for
|
|
262
|
+
instance:
|
|
263
|
+
|
|
264
|
+
alienv --no-refresh enter AliPhysics/latest
|
|
265
|
+
|
|
266
|
+
Note that the `--no-refresh` option is not necessary anymore starting from
|
|
267
|
+
`v1.4.0.rc1`.
|
|
268
|
+
|
|
269
|
+
### Building on Windows Ubuntu environment does not work
|
|
270
|
+
|
|
271
|
+
At the time of writing, neither Windows native nor the Ubuntu environment
|
|
272
|
+
on Windows are supported and most likely this will stay the same unless some
|
|
273
|
+
third party does the work and provides a pull request.
|
|
274
|
+
|
|
275
|
+
### Can I build on an unsupported architecture?
|
|
276
|
+
|
|
277
|
+
You can try, but of course your mileage might vary. In case the architecture is similar to one of the supported ones (e.g. Ubuntu and Kubuntu) this should be recognized automatically and the build should proceed, attempting to use the supported one. This will still not guarantee things will not break for some packages.
|
|
278
|
+
|
|
279
|
+
In case the architecture is completely unknown to us, you will get a message:
|
|
280
|
+
|
|
281
|
+
```
|
|
282
|
+
ERROR: Cannot autodetect architecture
|
|
283
|
+
```
|
|
284
|
+
|
|
285
|
+
if you still want to try, you can use the `--force-unknown-architecture` option and while we strive our best to help you out also in this case, sometimes priorities force us to simply ignore support requests.
|
|
286
|
+
|
|
287
|
+
### How do I run on a system where I do not have global install rights?
|
|
288
|
+
|
|
289
|
+
If you want to run on a system where you do not have global install rights, and
|
|
290
|
+
the PyYAML package is not installed (e.g. lxplus), you can still do so by using
|
|
291
|
+
the `--user` flag when you install with `pip`. This will install alibuild under
|
|
292
|
+
`~/.local/bin`.
|
|
293
|
+
|
|
294
|
+
This means that you need to do (only once):
|
|
295
|
+
|
|
296
|
+
pip install --user --upgrade alibuild
|
|
297
|
+
|
|
298
|
+
and then adapt you PATH to pickup the local installation, e.g. via:
|
|
299
|
+
|
|
300
|
+
export PATH=~/.local/bin:$PATH
|
|
301
|
+
|
|
302
|
+
|
|
303
|
+
### aliBuild keeps asking for my password
|
|
304
|
+
|
|
305
|
+
Some packages you may need to build have their source code in a protected repository on CERN GitLab.
|
|
306
|
+
This means that you may be asked for a username and password when you run `aliBuild build`.
|
|
307
|
+
See below for ways to avoid being prompted too often.
|
|
308
|
+
|
|
309
|
+
#### SSH authentication
|
|
310
|
+
|
|
311
|
+
You can use an SSH key to authenticate with CERN GitLab.
|
|
312
|
+
This way, you will not be prompted for your GitLab password at all.
|
|
313
|
+
To do this, find your public key (this usually lives in `~/.ssh/id_rsa.pub`) and copy the contents of the file into [your user settings on CERN GitLab][gitlab-ssh-key].
|
|
314
|
+
If you have no SSH key, you can generate one using the `ssh-keygen` command.
|
|
315
|
+
Then, configure git to use SSH to authenticate with CERN GitLab using the following command:
|
|
316
|
+
|
|
317
|
+
```bash
|
|
318
|
+
git config --global 'url.ssh://git@gitlab.cern.ch:7999/.insteadof' 'https://gitlab.cern.ch/'
|
|
319
|
+
```
|
|
320
|
+
|
|
321
|
+
[gitlab-ssh-key]: https://gitlab.cern.ch/-/user_settings/ssh_keys
|
|
322
|
+
|
|
323
|
+
#### Caching passwords
|
|
324
|
+
|
|
325
|
+
If you prefer not to use SSH keys as described above, you can alternatively configure git to remember the passwords you input for a short time (such as a few hours).
|
|
326
|
+
In order to do this, run the command below (which remembers your passwords for an hour each time you type them into git).
|
|
327
|
+
|
|
328
|
+
```bash
|
|
329
|
+
git config --global credential.helper 'cache --timeout 3600'
|
|
330
|
+
```
|
|
331
|
+
|
|
332
|
+
You can adjust the timeout (3600 seconds, above) to your liking, if you would prefer git to remember your passwords for longer.
|
|
333
|
+
|
|
334
|
+
#### I get an HTTP/2 related error
|
|
335
|
+
|
|
336
|
+
Some network provider do not support HTTP/2 apparently. If you get:
|
|
337
|
+
|
|
338
|
+
```bash
|
|
339
|
+
error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8)
|
|
340
|
+
```
|
|
341
|
+
|
|
342
|
+
or similar message, try to disable HTTP/2 with something like:
|
|
343
|
+
|
|
344
|
+
```
|
|
345
|
+
git config --global http.version HTTP/1.1
|
|
346
|
+
```
|