All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Böszörményi Zoltán" <zboszor@gmail.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: openembedded-core@lists.openembedded.org,
	Randy MacLeod <randy.macleod@windriver.com>,
	Khem Raj <raj.khem@gmail.com>
Subject: Re: [OE-core][PATCH 2/3] rpm-sequoia: New recipe for version 1.6.0
Date: Wed, 29 Jan 2025 10:14:29 +0100	[thread overview]
Message-ID: <1a79fe44-ae6b-4a93-b321-f938c7ad500e@gmail.com> (raw)
In-Reply-To: <CANNYZj-pUVu_vp7DERcSF__LcRWi3oA4hocfEqfKPW_KxmrGZg@mail.gmail.com>

2025. 01. 29. 10:05 keltezéssel, Alexander Kanavin írta:
> On Wed, 29 Jan 2025 at 09:09, Zoltán Böszörményi <zboszor@gmail.com> wrote:
>> +Subject: [PATCH 1/2] Make openssl the default signing crypto
>> +MIME-Version: 1.0
>> +Content-Type: text/plain; charset=UTF-8
>> +Content-Transfer-Encoding: 8bit
>> +
>> +Idea taken from the Fedora 41 rpm specfile, extended to build.rs
>> +to make it actually build. Give credit where credit is due: the
>> +Cargo.toml part of this patch is identical to the Fedora version.
>> +
>> +Signed-off-by: Fabio Valentini <decathorpe@gmail.com>
>> +Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>> +Upstream-Status: Inappropriate [Yocto specific]
>> +---
>> + Cargo.toml | 5 +----
>> + build.rs   | 8 +-------
>> + 2 files changed, 2 insertions(+), 11 deletions(-)
>> +
>> +diff --git a/Cargo.toml b/Cargo.toml
>> +index 7832878..1024cad 100644
>> +--- a/Cargo.toml
>> ++++ b/Cargo.toml
>> +@@ -43,11 +43,8 @@ crate-type = ["cdylib"]
>> +
>> + # We explicitly do not want to enable Sequoia's decompression support.
>> + # Hence we only select a crypto backend.
>> +-default = ["crypto-nettle"]
>> ++default = ["crypto-openssl"]
>> + crypto-nettle = ["sequoia-openpgp/crypto-nettle"]
>> + crypto-rust = ["sequoia-openpgp/crypto-rust"]
>> +-crypto-cng = ["sequoia-openpgp/crypto-cng"]
>> + crypto-openssl = ["sequoia-openpgp/crypto-openssl"]
>> +-crypto-botan = ["sequoia-openpgp/crypto-botan"]
>> +-crypto-botan2 = ["sequoia-openpgp/crypto-botan2"]
>> +
>> +diff --git a/build.rs b/build.rs
>> +index 1fdef4e..cdbbe88 100644
>> +--- a/build.rs
>> ++++ b/build.rs
>> +@@ -30,16 +30,10 @@ impl PkgConfigTemplate {
>> +             ("VERSION".to_string(), env!("CARGO_PKG_VERSION").to_string()),
>> +             ("HOMEPAGE".to_string(), env!("CARGO_PKG_HOMEPAGE").to_string()),
>> +             ("REQUIRES".to_string(),
>> +-             if cfg!(feature = "crypto-botan") {
>> +-                 "botan-3"
>> +-             } else if cfg!(feature = "crypto-botan2") {
>> +-                 "botan-2"
>> +-             } else if cfg!(feature = "crypto-nettle") {
>> ++             if cfg!(feature = "crypto-nettle") {
>> +                  "nettle"
>> +              } else if cfg!(feature = "crypto-openssl") {
>> +                  "libssl"
>> +-             } else if cfg!(feature = "crypto-cng") {
>> +-                 ""
>> +              } else if cfg!(feature = "crypto-rust") {
>> +                  ""
>> +              } else {
> I don't understand. It seems like this changes the default crypto
> choice, but why not simply pass openssl selection as a parameter from
> the recipe?
>
>> + Cargo.lock | 1049 +++++++++++++++++++++++++++++++---------------------
> If this is updated correctly, then the change to cargo class in
> another patch should not be necessary.
>
> Also, this file is going to be a royal pain to keep updated with
> sequoia version updates. Another reason not to patch rust sources when
> it can be avoided.
>
>
>
>> +++ b/meta/recipes-devtools/rpm-sequoia/rpm-sequoia_1.6.0.bb
>> @@ -0,0 +1,40 @@
>> +SUMMARY = "An OpenPGP backend for rpm using Sequoia PGP"
>> +HOMEPAGE = "https://sequoia-pgp.org/"
>> +LICENSE = "LGPL-2.0-or-later & Apache-2.0 & BSL-1.0 & MIT & Unicode-DFS-2016 & (Apache-2.0 | MIT) & (MIT | Apache-2.0 | Zlib) & (Unlicense | MIT)"
> This is very elaborate, how was it determined? How to ensure it remains correct?
>
>> +LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=f0ff5ff7747cf7d394079c6ae87f5f0c"
>> +
>> +DEPENDS = "openssl"
>> +
>> +inherit pkgconfig rust cargo cargo-update-recipe-crates
>> +
>> +CARGO_USE_OFFLINE_FLAG = "1"
> As explained above, this should not be needed if Cargo.lock is correct.
>
>> +export CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_DEBUG = "true"
> Why? Things like this need a comment in the recipe.
>
>> +do_compile:prepend () {
>> +       mkdir -p ${S}/target/release
>> +}
> Why?

For the same reason your own half baked recipe has it.
https://git.yoctoproject.org/poky-contrib/tree/meta/recipes-devtools/rpm/rpm-sequoia_1.5.0.bb?h=akanavin/package-version-updates-later

| Caused by:
|   process didn't exit successfully: 
`/home/zozo/yocto-5.2/tmp-sicom/work/corei7-64-oe-linux/rpm-sequoia/1.6.0/build/target/release/build/rpm-sequoia-cae33956cd11baf0/build-script-build` 
(exit status: 101)
|   --- stderr
|   thread 'main' panicked at build.rs:119:36:
|   Creating 
"/home/zozo/yocto-5.2/tmp-sicom/work/corei7-64-oe-linux/rpm-sequoia/1.6.0/sources-unpack/git/target/release/rpm-sequoia.pc" 
(CARGO_TARGET_DIR: None): Os { code: 2, kind: NotFound, message: "No such file or directory" }
|   stack backtrace:
|      0: rust_begin_unwind
|      1: core::panicking::panic_fmt
|      2: core::result::unwrap_failed
|      3: core::result::Result<T,E>::expect
|                at 
/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:1059:23
|      4: build_script_build::main
|                at ./build.rs:119:18
|      5: core::ops::function::FnOnce::call_once
|                at 
/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
|   note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


>
>> +do_install () {
>> +       mkdir -p ${D}${libdir}
>> +       install -m0755 ${B}/target/${RUST_TARGET_SYS}/release/librpm_sequoia.so ${D}${libdir}/librpm_sequoia.so.1
>> +       ln -s librpm_sequoia.so.1 ${D}${libdir}/librpm_sequoia.so
>> +
>> +       mkdir -p ${D}${libdir}/pkgconfig
>> +       install -m644 ${S}/target/release/rpm-sequoia.pc ${D}${libdir}/pkgconfig
>> +}
> Why can't we use upstream's standard install procedure? Also,
> cargo.bbclass has an install function, why is it completely replaced?
>
> Alex



  reply	other threads:[~2025-01-29  9:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-29  8:09 [OE-core][PATCH 1/3] cargo.bbclass: Allow using --offline instead of --frozen Zoltán Böszörményi
2025-01-29  8:09 ` [OE-core][PATCH 2/3] rpm-sequoia: New recipe for version 1.6.0 Zoltán Böszörményi
2025-01-29  9:05   ` Alexander Kanavin
2025-01-29  9:14     ` Böszörményi Zoltán [this message]
2025-01-29  9:20     ` Böszörményi Zoltán
2025-01-29  9:29       ` Alexander Kanavin
2025-01-29 10:09         ` Böszörményi Zoltán
     [not found]       ` <181F1FDA3B65007A.31881@lists.openembedded.org>
2025-01-29  9:41         ` Alexander Kanavin
2025-01-29  8:09 ` [OE-core][PATCH 3/3] rpm: Automatically enable using rpm-sequoia for signed packages Zoltán Böszörményi
2025-01-29  8:56   ` Alexander Kanavin
2025-01-29 10:34     ` Böszörményi Zoltán
2025-01-29 10:54       ` Alexander Kanavin
2025-01-29  8:49 ` [OE-core][PATCH 1/3] cargo.bbclass: Allow using --offline instead of --frozen Alexander Kanavin
2025-01-29  9:00   ` Böszörményi Zoltán
2025-01-29  9:08     ` Alexander Kanavin
2025-01-29  9:36 ` Yoann Congal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a79fe44-ae6b-4a93-b321-f938c7ad500e@gmail.com \
    --to=zboszor@gmail.com \
    --cc=alex.kanavin@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=randy.macleod@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.