Re: [gentoo-dev] [PATCH 1/3] dotnet.eclass: pass -S to file to disable seccomp
> On 3 Jan 2023, at 11:47, Ulrich Mueller wrote:
>
>> On Tue, 03 Jan 2023, Sam James wrote:
>
>> - if [[ "$(file "${exe}")" == *"shell script text"* ]]
>> + if [[ "$(file -S "${exe}")" == *"shell script text"* ]]
>
> POSIX file doesn't know the -S option. Could that cause any problems,
> e.g. on prefix systems?
I think it should be okay as we add our own PATH first. But it's a fair point.
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?
m1027 wrote: > Wow, wasn't aware of catalyst at all. What a beast in terms of control. It's not so well-known maybe because it was created by and for gentoo-releng but if you know what you want it's a fantastic tool. > (FYI: I enjoyed the links on catalyst you sent me directly. > Unfortunatelly I cannot answer you directly due to the default > TLS guarantee Thanks! Glad you liked them. And yes, TLS is on my list. > While being able to build exact environments with catalyst I wonder > how it could help fixing the issue of my original post. Thank you for connecting back to the original post! Let's see: > Whenever we need to deliver a updated app to customers whose OS is > too old (but updating it is too risky), we could either > a) keep evenly outdated dev build OSes around forever (oh no!), or > b) post our newly built app in a container (leaving the lovely native > world); and both ignore the fact that customers wish maintenance of > the entire OS actually, too. > So, ideally, there is c): In a hypothetic case we would prepare a > entire OS incl. our app (maybe via catalyst?) which would require > a bootloader-like mini-OS on the customer's side, to receive updates > over the internet, switch the OS at boot time, and fallback. I had a) in mind. Why "oh no!" ? I didn't mean forever. I think it's already a very good value proposition that you can deliver updates of your apps for the particular systems that your customers run. catalyst building specific, "old-like" OSes on which you build new (binpkg) versions of your app to be installable by emerge on old customer OSes is admittedly a lot of work, at least initially. Separate from those app updates you can then use catalyst to also tackle OS maintenance/updates. You can create either full milestone OSes or just individual (binpkg) packages through which customers' OSes can become less fragmented over time, at the pace each customer is comfortable with. OS updates can take only small steps at a time, since catalyst allows exact control. This could reduce target OS diversity drastically over time with probably relatively moderate development effort. More effort might go into holding customer hands along the bespoke update paths. So, I see controlled paths forward in both problem dimensions. I don't know if the effort is actually practical for you but it /is/ doable and most importantly it can be customized for the individual systems currently in production at your customers. //Peter
[gentoo-dev] [PATCH] linux-mod.eclass: Fix MODULESD_* for hyphenated modules (bug #889752)
From: Steven Stallion
Use of the MODULESD__{ADDITIONS,ALIASES,EXAMPLES} variables do not
currently work with external modules that are hyphenated. The current behavior
results in an invalid modprobe.d file containing partially evaluated content.
This appears to be due to use of ${currm} rather than ${currm_t} when
Referencing variables. This changes the use of ${currm} to ${currm_t} when
referencing variables to resolve this issue.
Closes: https://bugs.gentoo.org/889752
---
eclass/linux-mod.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index d14bbf7d9ea..6cf9969b19a 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -408,7 +408,7 @@ generate_modulesd() {
for((t=0; t<${module_aliases}; t++))
do
- echo "alias $(eval echo
\${MODULESD_${currm}_ALIASES[$t]})" \
+ echo "alias $(eval echo
\${MODULESD_${currm_t}_ALIASES[$t]})" \
>> "${module_config}"
done
echo '' >> "${module_config}"
@@ -434,7 +434,7 @@ generate_modulesd() {
fi
#---
- if [[ $(eval echo \${MODULESD_${currm}_ALIASES[0]}) == guess
]]; then
+ if [[ $(eval echo \${MODULESD_${currm_t}_ALIASES[0]}) == guess
]]; then
# So, let's do some guesswork, eh?
if [[ -n ${module_opts} ]]; then
echo "# For Example..." >> "${module_config}"
@@ -449,7 +449,7 @@ generate_modulesd() {
echo "# For Example..." >> "${module_config}"
echo "# --" >> "${module_config}"
for ((t=0; t<${module_examples}; t++)); do
- echo "options $(eval echo
\${MODULESD_${currm}_EXAMPLES[$t]})" \
+ echo "options $(eval echo
\${MODULESD_${currm_t}_EXAMPLES[$t]})" \
>> "${module_config}"
done
echo '' >> "${module_config}"
@@ -458,7 +458,7 @@ generate_modulesd() {
#---
if [[ ${module_additions} -gt 0 ]]; then
for ((t=0; t<${module_additions}; t++)); do
- echo "$(eval echo
\${MODULESD_${currm}_ADDITIONS[$t]})" \
+ echo "$(eval echo
\${MODULESD_${currm_t}_ADDITIONS[$t]})" \
>> "${module_config}"
done
echo '' >> "${module_config}"
--
2.39.0
Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?
Hi, On Mon 02 Jan 2023 23:31:17 GMT, m1027 wrote: > I am not complaining here. Hey, we are on rolling release. Some of > you may even know individual solutions to work around each of it. > However, we just may get into trouble when distributing newly > compiled apps (on new Gentoo systems) to older Gentoo systems. And > we don't know in advance. I am looking for the best way to avoid > that. It’s not really a production environment, but I have this hobby infra I’ve set up when I was a student an my solution is to have a VM compiling the big packages (gcc, glibc, llvm, php, etc.) and publish a binary repo from that. Then, every VM pulls this, and compile what’s specific on top of that. Everything is handled by crons. So far it works. One thing to get in mind is that, if a VM got stuck to an old commit (e.g. because one package needed a use change and emerge fails to update world due to that), I’m always re-compiling everything, because I’m scared of glibc or ncurses ABI breaks. My scale is ~30 VMs on 4 physical servers. -- Alarig
Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?
Am 04.01.23 um 23:00 schrieb m1027: Wow, wasn't aware of catalyst at all. What a beast in terms of control. (FYI: I enjoyed the links on catalyst you sent me directly. Unfortunatelly I cannot answer you directly due to the default TLS guarantee kicked in by my provider: "TLS is required, but was not offered by host". That's usually to be fixed on the receiving side.) While being able to build exact environments with catalyst I wonder how it could help fixing the issue of my original post. To sum up: Whenever we need to deliver a updated app to customers whose OS is too old (but updating it is too risky), we could either a) keep evenly outdated dev build OSes around forever (oh no!), or b) post our newly built app in a container (leaving the lovely native world); and both ignore the fact that customers wish maintenance of the entire OS actually, too. So, ideally, there is c): In a hypothetic case we would prepare a entire OS incl. our app (maybe via catalyst?) which would require a bootloader-like mini-OS on the customer's side, to receive updates over the internet, switch the OS at boot time, and fallback. I was recently playing with systemd-boot and it's interesting try-boot feature. So essentially it sounds like you want something similar to Yocto / Poky / Petalinux for the non-embedded world (and based on Gentoo of course; it sounds like catalyst is something like that)? Petalinux / Yocto is essentially a cross compiling environment with rootfs, etc. And after everything has been built, the rootfs is just packaged into a flashable ext4-image or something. So your devs wouldn't need to work on a (slightly) outdated system, just use the (in this case non-)cross-compiling environment with its own, separate rootfs. Is, e.g., crossdev able to build a non-cross, native compiler? It already provides a rootfs-folder and a separate emerge-config, etc... Just throwing crazy ideas around, what about using net-boot for your customer? This way they just need to store an image somewhere and can update it whenever necessary. Or (ab-)using an initramfs. Or u-boot bootloader, just like in the embedded world. Depending on the size of the actual OS/rootfs, taking ideas from e.g. Android with their A/B bootslots (i.e. two root-partitions or something, where one is active and the other can be updated with clever scripts, after a reboot they are swapped). OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?
peter: > Peter Stuge wrote: > > Essentially you will be maintaining a private fork of gentoo.git, > > If this seems too heavy handed then you can just as well do the reverse: > > Maintain an overlay repo with the packages you care to control in the > state you care to have them, set that in the catalyst stage4.spec > portage_overlay and add unwanted package versions in gentoo.git to > the package.mask directory used by catalyst. > > This may sound complicated but it isn't bad at all. > > For total control also make your own profile, e.g. based on embedded, > but that's not per se neccessary, only if the standard profiles has too > much conflicts with what you want in @system. > > catalyst will rebuild @system according to spec file but with too much > difference that just becomes annoying and feels more trouble than a > controlled profile. > > This approach falls somewhere between your options (1) and (5). Wow, wasn't aware of catalyst at all. What a beast in terms of control. (FYI: I enjoyed the links on catalyst you sent me directly. Unfortunatelly I cannot answer you directly due to the default TLS guarantee kicked in by my provider: "TLS is required, but was not offered by host". That's usually to be fixed on the receiving side.) While being able to build exact environments with catalyst I wonder how it could help fixing the issue of my original post. To sum up: Whenever we need to deliver a updated app to customers whose OS is too old (but updating it is too risky), we could either a) keep evenly outdated dev build OSes around forever (oh no!), or b) post our newly built app in a container (leaving the lovely native world); and both ignore the fact that customers wish maintenance of the entire OS actually, too. So, ideally, there is c): In a hypothetic case we would prepare a entire OS incl. our app (maybe via catalyst?) which would require a bootloader-like mini-OS on the customer's side, to receive updates over the internet, switch the OS at boot time, and fallback. I was recently playing with systemd-boot and it's interesting try-boot feature. Thanks
[gentoo-dev] [PATCH] eclass/dune.eclass: introduce edune and dune-compile (v3)
edune is a thin wrapper for dune, which will help to run special,
uncommon dune commands;
dune-compile is a function to selectively pick which packages will be
compiled "for-release" (as dune call it);
dune-compile without any arguments replaces the current dune_src_compile
Signed-off-by: Maciej Barć
---
eclass/dune.eclass | 114 -
1 file changed, 103 insertions(+), 11 deletions(-)
diff --git a/eclass/dune.eclass b/eclass/dune.eclass
index 4bc73eda8..655a41be8 100644
--- a/eclass/dune.eclass
+++ b/eclass/dune.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: dune.eclass
@@ -29,7 +29,7 @@ _DUNE_ECLASS=1
# Set before inheriting the eclass.
: ${DUNE_PKG_NAME:=${PN}}
-inherit multiprocessing
+inherit edo multiprocessing
# Do not complain about CFLAGS etc since ml projects do not use them.
QA_FLAGS_IGNORED='.*'
@@ -44,16 +44,108 @@ BDEPEND="
dev-ml/dune
"
+# @FUNCTION: edune
+# @USAGE: ...
+# @DESCRIPTION:
+# A thin wrapper for the `dune` command.
+# Runs `dune` with given arguments and dies on failure.
+#
+# Example use:
+# @CODE
+# edune clean
+# @CODE
+edune() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ edo dune "${@}"
+}
+
+# @FUNCTION: dune-release
+# @USAGE: [--target target] [package] ...
+# @DESCRIPTION:
+# Run a selected subcommand for either all of dune packages in current
+# directory or only the selected packages. In case of all packages the package
+# detection is done via dune itself.
+# The `--target` option specifies a target for the selected subcommand,
+# it is primarily used for `dune build`, for more info see `man dune-build`.
+#
+# Example use:
+# @CODE
+# dune-release build --target @install menhir menhirLib menhirSdk
+# @CODE
+dune-release() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ local subcommand
+ local target
+
+ # Get the subcommand.
+ if [[ -z "${1}" ]] ; then
+ die "dune-release: missing subcommand"
+ else
+ subcommand="${1}"
+ shift
+ fi
+
+ # Detect if the target is specified.
+ case "${1}" in
+ --target )
+ target="${2}"
+ shift
+ shift
+ ;;
+ esac
+
+ local -a myduneopts=(
+ --display=short
+ --profile release
+ -j $(makeopts_jobs)
+ )
+
+ # Resolve the package flag.
+ if [[ -n "${1}" ]] ; then
+ myduneopts+=( --for-release-of-packages="$(IFS="," ; echo
"${*}")" )
+ fi
+
+ edune ${subcommand} ${target} "${myduneopts[@]}"
+}
+
+# @FUNCTION: dune-compile
+# @USAGE: [package] ...
+# @DESCRIPTION:
+# Builds either all of or selected dune packages in current directory.
+#
+# Example use:
+# @CODE
+# dune-compile menhir menhirLib menhirSdk
+# @CODE
+dune-compile() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ dune-release build --target @install "${@}"
+}
+
+# @FUNCTION: dune-test
+# @USAGE: [package] ...
+# @DESCRIPTION:
+# Tests either all of or selected dune packages in current directory.
+#
+# Example use:
+# @CODE
+# dune-test menhir menhirLib menhirSdk
+# @CODE
+dune-test() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ dune-release runtest "${@}"
+}
+
dune_src_compile() {
- ebegin "Building"
- dune build @install -j $(makeopts_jobs) --profile release
- eend $? || die
+ dune-compile
}
dune_src_test() {
- ebegin "Testing"
- dune runtest -j $(makeopts_jobs) --profile release
- eend $? || die
+ dune-test
}
# @FUNCTION: dune-install
@@ -67,6 +159,8 @@ dune_src_test() {
# dune-install menhir menhirLib menhirSdk
# @CODE
dune-install() {
+ debug-print-function ${FUNCNAME} "${@}"
+
local -a pkgs=( "${@}" )
[[ ${#pkgs[@]} -eq 0 ]] && pkgs=( "${DUNE_PKG_NAME}" )
@@ -79,9 +173,7 @@ dune-install() {
local pkg
for pkg in "${pkgs[@]}" ; do
- ebegin "Installing ${pkg}"
- dune install ${myduneopts[@]} ${pkg}
- eend $? || die
+ edune install ${myduneopts[@]} ${pkg}
# Move docs to the appropriate place.
if [[ -d "${ED}/usr/doc/${pkg}" ]] ; then
--
2.38.2
