Searched refs:changes (Results 1 – 25 of 884) sorted by relevance
12345678910>>...36
21 - Kernel-related changes:27 - Architecture-specific changes:29 - QEMU / ``runqemu`` changes:31 - Documentation changes:33 - Go changes:35 - Rust changes:37 - Wic Image Creator changes:39 - SDK-related changes:41 - Testing-related changes:43 - Utility script changes:[all …]
38 Rust language changes41 systemd changes44 Recipe changes67 Miscellaneous changes
41 .. _migration-4.3-compiling-changes:43 Compiling changes82 .. _migration-4.3-go-changes:84 Go language changes90 .. _migration-4.3-systemd-changes:92 systemd changes99 .. _migration-4.3-recipe-changes:101 Recipe changes141 - ``glide``: as explained in :ref:`migration-4.3-go-changes`.155 - ``glide``: as explained in :ref:`migration-4.3-go-changes`.[all …]
12 .. _migration-5.1-workdir-changes:14 :term:`WORKDIR` changes53 without changes. We cannot use symlinks to do this as it breaks autotools55 as it meant more invasive recipes changes. The key objective was separating the58 Previously, :term:`S` was always created but after the recent changes it is no102 .. _migration-5.1-go-changes:104 Go language changes116 .. _migration-5.1-systemd-changes:118 systemd changes125 .. _migration-5.1-recipe-changes:[all …]
50 .. _migration-5.0-go-changes:52 Go language changes59 .. _migration-5.0-systemd-changes:61 systemd changes70 .. _migration-5.0-recipe-changes:72 Recipe changes122 .. _migration-5.0-qemu-changes:124 QEMU changes132 ipk packaging changes167 .. _migration-5.0-misc-changes:[all …]
19 .. _migration-1.6-packaging-changes:24 The following packaging changes have been made:47 The following changes have been made to :term:`BitBake`.123 .. _migration-1.6-variable-changes:131 .. _migration-1.6-variable-changes-TMPDIR:143 .. _migration-1.6-variable-changes-PRINC:149 detected during a build. For :term:`PR` increments on changes,154 .. _migration-1.6-variable-changes-IMAGE_TYPES:163 .. _migration-1.6-variable-changes-COPY_LIC_MANIFEST:171 .. _migration-1.6-variable-changes-COPY_LIC_DIRS:[all …]
11 …changes to Vim yourself, you must clearly describe in the distribution how to contact you. When th…13 …dified, as mentioned at I). If you make additional changes the text under a) applies to those chan…15 …changes, including source code, with every copy of the modified Vim you distribute. This may be do…17 …a modified Vim which includes changes as mentioned under c), you can distribute it without the sou…18 …e changes permits you to distribute the changes to the Vim maintainer without fee or restriction, …19 …changes for at least three years after last distributing the corresponding modified Vim. When the …22 …e) When the GNU General Public License (GPL) applies to the changes, you can distribute the modifi…24 …essage is only required for as far as this does not conflict with the license used for the changes.28 …changes and make them available to the maintainer, including the source code. The preferred way to…
6 to initial any changes you make so that if I like the changes I can
29 self.changes = {}41 if not self.changes.get(version):42 self.changes[version] = []43 self.changes[version].append(info)
38 self.changes = {}159 for change in sorted(self.changes, reverse=True):161 for this_commit, text in self.changes[change]:178 if self.changes:189 changes_copy = dict(self.changes)191 if self.changes.get(version):200 elif self.changes:268 if not self.changes.get(version):269 self.changes[version] = []270 self.changes[version].append([commit, info])
5 Configuration changes that should be applied to a device or regulator rail.6 These changes usually override hardware default settings.12 The configuration changes are applied during the boot before regulators are15 The configuration changes are applied by executing one or more actions. The26 …gs | One or more comment lines describing the configuration changes. …
19 …nfiguration changes that should be applied to this rail. These changes usually override hardware d…
450 changes = []516 changes.append(chg)517 return changes547 changes = collections.OrderedDict()569 entry = changes.get(m.hexdigest(), (line, []))571 changes[m.hexdigest()] = (line, entry[1] + [desc])589 for key, item in changes.items():622 changes = []627 changes.append(compare_siglists(d.a_blob, d.b_blob, taskdiff=sigsdiff))628 return changes[all …]
15 repository, build, and test your changes within QEMU.20 changes within QEMU.25 your changes for code review.
97 changes and push them to Gerrit for code review. Here is what the basic workflow100 - Make your code changes103 - Commit your changes, adding a Signed-off-by line to it (more on104 … commit messages](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes)):106 - Push your changes to Gerrit for code review:114 set up Gerrit and know how to submit your code changes for review!116 Submitting changes for review is just one of many steps in the contributing
7 that allows you to capture source code changes without having a clean9 modify source code, test changes, and then preserve the changes in the14 With regard to preserving changes to source files, if you clean a45 #. *Edit the Files:* Make your changes in the source code to the files49 easiest way to test your changes is by calling the :ref:`ref-tasks-compile`68 #. *Generate the Patch:* Once your changes work as expected, you need to
184 .PHONY: changes185 changes: target186 $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
79 changes = 088 changes += int(file_data["insertions"]) + abs(93 if changes < 10:
3 When making changes to the Redfish tree, please follow the checklist below.12 2. Document any client-facing changes in behavior in the commit message. Note,13 that this should include behavior changes that may not affect your system.25 Redfish change. Most changes require more tests than simply service
35 changes: int = 0 variable in UpdateSubprojects92 self.changes += 1132 self.changes += 1179 if self.changes:
13 echo Your changes must meet the upstream meson style guide39 # configuration will catch any unexpected changes in the library implementation
89 for your changes, starting from the reference branch in the upstream93 $ git checkout -b my-changes95 If you have completely unrelated sets of changes to submit, you should even98 Implement and commit changes101 In each branch, you should group your changes into small, controlled and102 isolated ones. Keeping changes small and isolated aids review, makes108 …e <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes>`__116 #. *Stage Your Changes:* Stage your changes by using the ``git add``168 changes. Thus, providing something short and descriptive that218 tested your changes or reviewed their code. These fields are[all …]
60 to separating source changes.63 minimal changes to the sources, the released recipes provide a vetted64 base upon which to layer your changes. Doing so allows you to benefit100 kernel recipes. Configuration changes can be added in the form of136 if you have to do this, you make the changes to the files in the151 interactively develop and test the configuration changes you are152 making to the kernel. Saving changes you make with ``menuconfig``162 Once you are satisfied with the configuration changes made using165 those changes into a173 image applies your changes. Depending on your target hardware, you[all …]
153 is usually named "poky", allows you to make changes, contribute to the235 responsible for accepting changes from other developers and for250 area. These branches hold changes (commits) to the project that have253 determines if the changes are qualified to be moved from the "contrib"259 develop changes. When a developer is satisfied with a particular feature270 There is a somewhat formal method by which developers commit changes and274 submitting patches and changes, see the275 ":doc:`../contributor-guide/submit-changes`" section in the Yocto Project278 In summary, there is a single point of entry for changes into the281 develop, test, and submit changes to "contrib" areas for the maintainer[all …]
10 This section details how the project tests changes, through automation14 The project aims to test changes against our test matrix before those15 changes are merged into the master branch. As such, changes are queued29 If successful, the changes would usually be merged to the ``master``30 branch. If not successful, someone would respond to the changes on the32 of quick or full would depend on the type of changes and the speed with