- 17 Jan, 2022 27 commits
-
-
Hans van Kranenburg authored
[git-debrebase make-patches: export and commit patches]
-
The objdump output is fed to grep, so make sure it doesn't change with different user locales and break the grep parsing. This problem was identified while updating xen in Debian and the fix is needed for generating reproducible builds in varying environments. Signed-off-by:
Maximilian Engelhardt <maxi@daemonizer.de> -
Use the solution described in [1] to replace the call to the 'date' command with a version that uses SOURCE_DATE_EPOCH if available. This is needed for reproducible builds. [1] https://reproducible-builds.org/docs/source-date-epoch/ Signed-off-by:
Maximilian Engelhardt <maxi@daemonizer.de>
[Hans van Kranenburg]
Note: this patch is submitted upstream but not committed yet. We
expect that it gets in. Otherwise, we don't wait and already have it
here because I want to have the reproducible build work completed. -
Hans van Kranenburg authored
This is something that hasn't been touched (except for making it Python 3 compatible, which failed) since 2007. Don't build or ship it. -# xenmon File "/usr/sbin/xenmon", line 680 stop_cmd = "/usr/bin/pkill -INT -z global xenbaked" TabError: inconsistent use of tabs and spaces in indentation Signed-off-by:Hans van Kranenburg <hans@knorrie.org>
-
Hans van Kranenburg authored
We have the `xen` alias for xl in Debian, since in the past it was a command that could execute either xl or xm. Now, it always does xl, so, complete the same stuff for it as we have for xl. Signed-off-by: -
If LIBEXEC_LIB is not on the default linker search path, the python fsimage.so module fails to find libfsimage.so. Add the relevant directory to the rpath explicitly. (This situation occurs in the Debian package, where --with-libexec-libdir is used to put each Xen version's libraries and utilities in their own directory, to allow them to be coinstalled.) Signed-off-by:
Ian Jackson <ian.jackson@citrix.com> -
We install libfsimage in a non-standard path for Reasons. (See debian/rules.) This patch was originally part of `tools-pygrub-prefix.diff' (eg commit 51657319 ) and included changes to the Makefile to change the installation arrangements (we do that part in the rules now since that is a lot less prone to conflicts when we update) and to shared library rpath (which is now done in a separate patch). (Commit message rewritten by Ian Jackson.) Signed-off-by:
Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath -
This is in the upstream script because on non-Debian systems, the default install locations in /usr/local/lib might not be on the linker path, and as a result the hotplug scripts would break. A reason we might need it in Debian is our multiple version coinstallation scheme. However, the hotplug scripts all call the utilities via the wrappers, and the binaries are configured to load from the right place anyway. This setting is an annoyance because it requires libdir, which is an arch-specific path but comes from a file we want to put in xen-utils-common, an arch:all package. So drop this setting. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Hans van Kranenburg authored
Strip all options that are for stuff we don't ship, which is 1) xenstored as stubdom and 2) the new options for oom score and open file descriptor limit, which would not have any effect, because we're shipping different init scripts... :| It seems useful to give the user the option to revert to xenstored instead of the default oxenstored if they really want. Signed-off-by:
Ian Jackson <ijackson@chiark.greenend.org.uk> -
Hans van Kranenburg authored
Also see Debian bug #894013. The current attempt at providing anti-spoofing rules results in a situation that does not have any effect. Also note that forwarding bridged traffic to iptables is not enabled by default, and that for openvswitch users it does not make any sense. So, stop cluttering the live iptables ruleset. This functionality seems to be introduced before 2004 and since then it has never got some additional love. It would be nice to have a proper discussion upstream about how Xen could provide some anti mac/ip spoofing in the dom0. It does not seem to be a trivial thing to do, since it requires having quite some knowledge about what the domU is allowed to do or not (e.g. a domU can be a router...). Signed-off-by: -
This manpage was omitted from docs/man: Provide properly-formatted NAME sections because I was previously building with markdown not installed. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
When building on a 32-bit userland, the user wants to build 32-bit tools and a 64-bit hypervisor. This involves setting XEN_TARGET_ARCH to different values for the tools build and the hypervisor build. So the user must invoke the tools build and the hypervisor build separately. However, although the shim is done by the tools/firmware Makefile, its bitness needs to be the same as the hypervisor, not the same as the tools. When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is wrong. So the user must invoke the shim build separately. This can be done with make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64 However, tools/firmware/xen-dir has no `install' target. The installation of all `firmware' is done in tools/firmware/Makefile. It might be possible to fix this, but it is not trivial. For example, the definitions of INST_DIR and DEBG_DIR would need to be copied, as would an appropriate $(INSTALL_DIR) call. For now, provide an `install-shim' target in tools/firmware/Makefile. This has to be called from `install' of course. We can't make it a dependency of `install' because it might be run before `all' has completed. We could make it depend on a `shim' target but such a target is nearly impossible to write because everything is done by the inflexible subdir-$@ machinery. The overally result of this patch is that existing make invocations work as before. But additionally, the user can say make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64 to install the shim. The user must have built it already. Unlike the build rune, this install-rune is properly conditional so it is OK to call on ARM. What a mess. Signed-off-by:Ian Jackson <ijackson@chiark.greenend.org.uk> -
This makes it easier to disable the shim build. (In Debian we need to build the shim separately because it needs different compiler flags). Signed-off-by:
Ian Jackson <ijackson@chiark.greenend.org.uk>
[ Hans: adjust from tools/firmware/Makefile to config/Tools.mk.in to
follow changes that happened in 8845155c
("pvshim: make PV shim build
selectable from configure") ]
Signed-off-by: -
Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
This is going to be used to put libfsimage.so into a path containing the multiarch triplet. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Hans van Kranenburg authored
\o/
-
Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Patch-Name: tools-pygrub-remove-static-solaris-support Gbp-Pq: Topic misc Gbp-Pq: Name tools-pygrub-remove-static-solaris-support
-
This is not wanted in Debian. COPYING ends up in /usr/share/doc/xen-*copyright. Patch-Name: tools-include-no-COPYING.diff Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Patch-Name: config-prefix.diff Gbp-Pq: Topic prefix-abiname Gbp-Pq: Name config-prefix.diff
-
During hypervisor boot, disable the banner and nicely display the xen version as well as the Maintainer address from debian/control. For this to work the SOURCE_BASE_DIR variable needs to be set by the build system to the top directory, i.e. where the debian folder is. Original patch by Bastian Blank <waldi@debian.org> Modified by Hans van Kranenburg <hans@knorrie.org> Maximilian Engelhardt <maxi@daemonizer.de>
-
These autogenerated files are not useful in Debian; dh_autoreconf will regenerate them. If this patch does not apply when rebasing, you can simply delete the files again. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
dh_autoreconf will provide these back. If this patch does not apply when rebasing, you can simply delete the files again. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Hans van Kranenburg authored
Ian does not work at Citrix any more now, but he keeps the xenproject address. Signed-off-by: -
Hans van Kranenburg authored
Signed-off-by: -
These are currently not used and not needed. Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de> -
During the Debian 11 release cycle, we did a Xen upload at the same time when a transition of default Python version (from 3.8 to 3.9) was happening. This exposed a problem: Our xen-utils-V package just depended on 'python3'. Why was this a problem? We ship a compiled extension, which gets built for the *default* Python version in the system. In this case it was the xenfsimage.cpython-39-x86_64-linux-gnu.so file (note the 39 in the name). Having just the quite generic 'python3' dependency allowed our packages to enter Debian testing before the transition of default Python version (from 3.8 to 3.9) did. As a result, the xenfsimage library could not be found, because the user system would still be looking for [...]cpython-38[...]. To generate correct dependencies, dh-python >= 5.20211016 (which includes a fix for #980303) is needed. In the above case, the correct dependencies that would need to be added are: 'python3 (<< 3.10), python3 (>= 3.9~)'. Having these dependencies in place would make sure our packages enter testing at the same time as the default change to Python would. The actual patch in here is quite small, but not easy to understand as multiple other bugs are also intertwined, so here follows more explanation. First, this patch reverts 1ca529cc ("debian/control: fix xen-utils-4.14 python3 dependency"), which was a workaround for a missing python3 dependency in the xen-utils-V package. This problem happened due to the dynamic ${python3:Depends} back in) is a prerequisite for the second part below. Second this patch adds scanning of the private directory "/usr/lib/xen-$(upstream_version)/lib/python" for dh-python to detect our private python extension and generate proper version dependencies for python3. This unfortunately was broken in dh-python (#980303), but is fixed since 5.20211016. This part is the fix for #976597. We were thinking about adding a build dependency to dh-python >= 5.20211016 to the xen source package, but decided to omit the version from the dependency for the following reasons: * A dh-python with all relevant fixes is meanwhile in unstable and testing. * We wanted to make backporting xen to bullseye easy and dh-python >= 5.20211016 is not in bullseye. Adding the versioned dependency would mean more manual work while doing the backport. We believe this is safe to do for the following reasons: * When building for unstable or testing in an up-to-date chroot there should be no issues as all relevant bugs in dh-python are fixed. * When building a backport for bullseye, proper version dependencies for python3 will not be generated, but also have not been generated in the past, so this is not a regression. And, the default python3 version in bullseye will very likely never change. * The revert of 1ca529cc might be seen as a problem as the dependency on python3 in xen-utils might be missing when compiled for bullseye. However this luckily does not happen because of our additional scan for private python extension in this commit. While the bullseye dh-python is buggy in a way that it doesn't generate proper version dependencies for python3 it still detects python3 usage and adds a 'python3' dependency. Signed-off-by:
Maximilian Engelhardt <maxi@daemonizer.de>
[ adding first three introductory paragraphs in the commit message ]
Signed-off-by:
-
- 17 Dec, 2021 10 commits
-
-
This fixes #988901 as now update-grub will be called by all packages that can affect the state of the update-grub generated output. Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de> -
Cross building xen currently fails due to Debian bug #982406 in markdown. It can be tried again when there are better chances of it building successfully. Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de> -
This makes it easier to switch to another distribution. Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de> -
It is enabled by default now. Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de> -
Hans van Kranenburg authored
It was already not possible to use x86_32 hardware because the i386 packages already shipped a 64-bit hypervisor and PV shim. Running 32-bit utils with a 64-bit hypervisor requires using a compatibility layer that is fragile and becomes harder to maintain and test upstream. The libc6-xen package is not being built any more, and 32-bit PV support also has been removed from the Linux kernel now. This change ends the 'grace period' in which users should have moved to using a fully 64-bit dom0. As a result the only reverse dependency for the libc6-xen package in Debian is also removed, so this also (Closes: #992909) in the process. Signed-off-by: -
Hans van Kranenburg authored
This was used in the past to check if input files for generating configuration were changed. It's no longer used now. Signed-off-by: -
This adds the SOURCE_BASE_DIR variable pointing to the top directory. The variable is then later used by the patch in our delta queue that adjusts the first hypervisor log line to insert Debian specific information. Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de> -
In upstream commit d2cad41d ("tools/libs/store: cleanup libxenstore interface") a number of functions in this library were removed, which results in a soname bump. Follow this change by now shipping libxenstore4 instead of 3.0.
-
replace 4.14 with 4.16 Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de> -
Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de>
-
- 04 Dec, 2021 3 commits
-
-
Hans van Kranenburg authored
[git-debrebase changelog: new upstream 4.16.0]
-
Hans van Kranenburg authored
[git-debrebase anchor: new upstream 4.16.0, merge]
-
Hans van Kranenburg authored
-
