@Conan-Kudo commented on this pull request.
> +
+mkdir -p "$BUILDINFO_DIR"
+
+cat > "$BUILDINFO" <> "$BUILDINFO"
I'm fine with another filename.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@Conan-Kudo commented on this pull request.
> +
+printf 'Installed-Build-Depends:\n' >> "$BUILDINFO"
+rpm -qa --queryformat '%{epoch}:%{name}-%{version}-%{release}.%{arch}\n' \
+| LC_ALL=C sort -t: -k2 \
+| sed -e 's/^(none)://; /\.(none)$/d; s/^/ /' >> "$BUILDINFO"
+
+printf
Koji has a similar build environment record, though it's stored in the Koji
database rather than as a file. We do archive environment artifacts from Mock
with builds too, though.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@woju commented on this pull request.
> +
+mkdir -p "$BUILDINFO_DIR"
+
+cat > "$BUILDINFO" <> "$BUILDINFO"
If you really insist on a different format for RPM, I'd suggest the file suffix
be changed to something else than `.buildinfo` (maybe `.rpmbuildinfo`?). This
will at least make
@woju commented on this pull request.
> +Format: 1.0-rpm
+Build-Architecture: $(uname -m)
+Source: $RPM_PACKAGE_NAME
+Epoch: $RPM_PACKAGE_EPOCH
+Version: ${RPM_PACKAGE_VERSION}
+Release: ${RPM_PACKAGE_RELEASE}
+Architecture: $RPM_ARCH
+Build-Origin: $(getos)
+Build-Path: $RPM_BUILD_DIR
> I
Interested in something like this for openSUSE. We already have something
comparable called `_buildenv` (XML) e.g. in
https://build.opensuse.org/package/binaries/openSUSE:Factory/bash/standard -
but that is created on the obs_worker level.
@fepitre commented on this pull request.
> +
+mkdir -p "$BUILDINFO_DIR"
+
+cat > "$BUILDINFO" <> "$BUILDINFO"
@Conan-Kudo thank you for your feedback and comments. Generally I would have
loved to have a generic format not being one distro specific to ease
manipulating this file among several
@bmwiedemann do you have some feedback to give from several comments here? As
you work on reproducible builds for openSUSE you are certainly interested by
this new feature.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@fepitre commented on this pull request.
> +
+printf 'Installed-Build-Depends:\n' >> "$BUILDINFO"
+rpm -qa --queryformat '%{epoch}:%{name}-%{version}-%{release}.%{arch}\n' \
+| LC_ALL=C sort -t: -k2 \
+| sed -e 's/^(none)://; /\.(none)$/d; s/^/ /' >> "$BUILDINFO"
+
+printf
@ffesti pushed 1 commit.
2019abae2439c5d3d4e250098b093e648a1f72d7 Require package names to be valid
provides
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@ffesti commented on this pull request.
> @@ -19,6 +19,7 @@
#undef HTDATATYPE
#define ALLOWED_CHARS_NAME ".-_+%{}"
+#define ALLOWED_FIRSTCHARS_NAME "_%{}"
Ok, after reading `rpmCharCheck()` 3 more times: Looks like `%{}`are actually
legal in dependency names and only create a warning. So
@DemiMarie requested changes on this pull request.
This needs #1705 or equivalent to ensure that non-`PGPSIGTYPE_BINARY`
signatures are not accepted as package signatures.
> + if (sigalg->setmpi(sigalg, i, p))
+ break;
This requires a corresponding change in the package signature
@pmatilai commented on this pull request.
> @@ -19,6 +19,7 @@
#undef HTDATATYPE
#define ALLOWED_CHARS_NAME ".-_+%{}"
+#define ALLOWED_FIRSTCHARS_NAME "_%{}"
Doh, missed the actual beef of the change there (once again...)
While we need to accept %{} from macro leakage in the names, { and }
@ffesti pushed 1 commit.
c1d631c94bf078936fcfe07b136344f924a112cd Require package names to be valid
provides
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai pushed 3 commits.
7b399fcb8f52566e6f3b4327197a85facd08db91 Process MPI's from all kinds of
signatures
236b802a4aa48711823a191d1b7f753c82a89ec5 Refactor pgpDigParams construction to
helper function
e233fb844adda74a5199057d1fd7fa20d994564d Validate and require subkey binding
@pmatilai commented on this pull request.
> @@ -19,6 +19,7 @@
#undef HTDATATYPE
#define ALLOWED_CHARS_NAME ".-_+%{}"
+#define ALLOWED_CHARS_NAME_FIRST "_%{}"
Ditto here, ALLOWED_FIRSTCHARS_NAME will be more obvious to the reader and
easier to grep for.
--
You are receiving this because
@pmatilai commented on this pull request.
> @@ -643,17 +643,27 @@ static void specLog(rpmSpec spec, int lvl, const char
> *line, const char *msg)
* @param allowedchars string of permitted characters
* @return RPMRC_OK if OK
*/
-rpmRC rpmCharCheck(rpmSpec spec, const char
I was close to hitting merge but stopped to see whether
brp-strip-static-archive is even used, only much to my surprise it was already
converted this way.
Fix the commit message to talk about brp-strip-comment-note instead
:sweat_smile:
--
You are receiving this because you are subscribed
It's a bit strange perhaps but I don't have any better ideas for the
compatibility either. Just update the docs and I'm fine with it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> if (pkttype == PGPTAG_SIGNATURE)
break;
+
+ if (alloced <= i) {
+ alloced *= 2;
To elaborate on that a bit, the suggested change is simply absurd when you
could simply place a simple upper bound and error out if
@pmatilai commented on this pull request.
> + /* ignore unknown types */
+ rc = 0;
No, rejecting types we cannot handle would only cause us to fail on perfectly
legitimate keys. IIRC the PGP spec quite specifically tells you to ignore what
you don't know, which generally is the key
@pmatilai commented on this pull request.
> + 0xb4,
+ (pkt->blen >> 24),
+ (pkt->blen >> 16),
+ (pkt->blen >> 8),
+ (pkt->blen ),
+ };
+ rpmDigestUpdate(hash, head, 5);
+ rpmDigestUpdate(hash, pkt->body, pkt->blen);
+
The subkey binding part simplified a bit and split to #1795, the user
certification is more involved and has all manner of strange open questions, I
don't have time to deal with that now. Thanks for the feedback so far.
--
You are receiving this because you are subscribed to this thread.
Reply
Closed #1788.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1788#event-5455103925___
Rpm-maint mailing list
All subkeys must be followed by a binding signature by the primary key as per
the OpenPGP RFC, enforce the presence and validity in the parser.
The implementation is as kludgey as they come to work around our simple-minded
parser structure without touching API, to maximise backportability.
@voxik commented on this pull request.
> +
+printf 'Installed-Build-Depends:\n' >> "$BUILDINFO"
+rpm -qa --queryformat '%{epoch}:%{name}-%{version}-%{release}.%{arch}\n' \
+| LC_ALL=C sort -t: -k2 \
+| sed -e 's/^(none)://; /\.(none)$/d; s/^/ /' >> "$BUILDINFO"
+
+printf
26 matches
Mail list logo
