Right now source RPMs get an ARCH tag set to the architecture of the machine
the package was built on (e.g. `i686`). We should set it to `src` instead, both
for clarity and to help with build reproducibility.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-
I'm hitting build failures for asahi-scripts in Rawhide, while it works fine on
f38:
```
error: line 100: Dependency tokens must begin with alpha-numeric, '_' or '/':
%transfiletriggerin -n update-m1n1 -- /usr/lib64/m1n1 /usr/share/uboot/apple_m1
/boot/dtb/apple
```
https://src.fedoraproject.o
To close the loop on this, we were able to fix our internal implementation by
switching to https://github.com/ProtonMail/go-crypto which includes a fix for
this (see
https://github.com/ProtonMail/go-crypto/commit/d3d8a14a4d4f772c205a10c24d14676522ee95d2).
--
Reply to this email directly or vie
> What implementation are you using to sign the rpm?
It's an internal implementation (that from what I can tell uses gpg under the
hood, but I need to double check). I will followup with the engineers that
developed it and see what we can find out. Thanks for the quick reply!
--
Reply to this
Put up a minimal package that repros the issue at
http://dcavalca.fedorapeople.org/fb-test-opengpg-20230113-083251.x86_64.rpm
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2351#issuecomment-1382122274
You are receiving this because yo
I have a number of RPMs that work fine on Fedora 37, but fail to validate on
Rawhide and ELN with `package tag 268: invalid OpenPGP signature`:
```
# rpm -qip fb-genchefserverlist-20230113-032842.x86_64.rpm
error: fb-genchefserverlist-20230113-032842.x86_64.rpm: Header RSA signature:
BAD (packa
Yes, it should work just fine. We actually have packaging for dcrpm at
https://github.com/facebookincubator/rpm-backports/tree/master/rpms/dcrpm that
we use on CentOS 7 (and macOS) with no issues.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
SELinux recommends to use string_to_security_class() instead of referencing
class IDs directly. This also fixes a build issue for systems that don't
include flask.h by default.
References:
https://selinuxproject.org/page/NB_Imp_SELinux-aware_Apps#Implementing_SELinux-aware_Applications_2
https://g
