OK, I looked into this and there are road blocks everywhere. Let's just stick
to the PR as is. I generally agree that this is not the way to do this but the
build code is an entangled mess and moving stuff round at this point is
something we just should not do.
Looking at all the hidden
Here's a simple and straightforward way source headers are always indentified
as such right after parse:
https://github.com/rpm-software-management/rpm/pull/3012
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
11599c994b870444ac3cbffb61a8256152f9f27a fixup! Ensure source headers are
identified as such after a spec parse
--
View it on GitHub:
Fixed with
https://github.com/rpm-software-management/rpmpgp_legacy/commit/31c2f3d017372ee11b6c7403f13889736757c046
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3001#issuecomment-2031713736
You are receiving this because you are
BTW it's worth noting that both the patches and sources appear in a reverse
order to how they're introduced in the spec. This is basically an internal
implementation detail (linked list operation) leaking into the packages, but
because it's always been that way, "fixing" would silently break
@Conan-Kudo requested changes on this pull request.
Actually, since these emit the sources and patches in reverse order, could we
make the aliases also reverse that so they are in the correct order?
--
Reply to this email directly or view it on GitHub:
Nice to see somebody besides ourselves being excited about this :smile:
And yeah that is really a big part of the point: rpm's data structures aren't
really that exotic, but to someone new it's all lost in the details of this
specific implementation, and then we have like three different
The code in doDefine() supports multiline macros, it's that nasty rdcl()
function that is to blame here.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2976#issuecomment-2031383183
You are receiving this because you are subscribed to
Yeah, I already noticed and fixed psm.c and tagexts.c. There is still something
wrong with the test case or the code or both. I update the patch ass soon as
this works.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -180,6 +180,34 @@ runroot rpmspec \
[])
RPMTEST_CLEANUP
+AT_SETUP([rpmspec -q --rpms])
+AT_KEYWORDS([query])
+RPMTEST_CHECK([
+RPMDB_INIT
+runroot rpmspec --rpms \
+ -q /data/SPECS/hello.spec | grep src
+runroot rpmspec --rpms \
+ -q
The build code is a mess for sure, but adding hacks on top of hacks only makes
it worse.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2995#issuecomment-2031613554
You are receiving this because you are subscribed to this thread.
Right, this is specific to the internal pgp parser. With rpm-sequoia I get:
> $ tools/rpmkeys --dbpath /tmp/kdb --import
> /tmp/2596A99EAAB33821893C0A79458CA832957F5868
error: Certificate 458CA832957F5868:
Policy rejects 458CA832957F5868: No binding signature at time
2024-04-02T10:42:20Z
Could you fix it for your rpmspec aliases though?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8982821
You are receiving this because you are subscribed to this thread.
Message ID:
I opened this ticket from the discussion specifically because it's such a
no-brainer when you see it: "tests should not be able to affect built
binaries". How feasible it is in practise is another story, but it's worth at
least investigating.
--
Reply to this email directly or view it on
headerIsSource() uses RPMTAG_SOURCERPM presence to identify binary packages,
but that tag gets inserted late in an actual package build, whereas wed
like to source headers to be identifiable right after spec parse already.
Non-presence of a tag is not a very strong indicator anyhow, and even
The query is not exactly obvious though, so:
https://github.com/rpm-software-management/rpm/pull/3011
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8980798
You are receiving this because you are subscribed
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3011#pullrequestreview-1973096004
You are receiving this because you are subscribed to this thread.
Message ID:
We've been entertaining ideas to this direction before the xz incident, eg
#2985 (for read-only source) and #2989. Read-only buildroot would be a logical
extension of this. Some of these things are stepping into "mock territory", but
then people still *do* run rpmbuild through other means as
Opened https://github.com/rpm-software-management/rpm/issues/3010 as well.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3009#discussioncomment-8980509
You are receiving this because you are subscribed to this thread.
Message
On the heels of the xz incident, one of the ideas (from @keszybz it seems) to
harden against malicious tests is to make buildroot readonly during %check.
Picked from https://github.com/rpm-software-management/rpm/discussions/3009 as
a clear actionable item.
--
Reply to this email directly or
There's not much you can do against a malicious upstream.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2031325567
You are receiving this because you are subscribed to this thread.
Message ID:
Took a quick look at my own suggestion in the earlier comment and it brings out
some truly WTF failures :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2995#issuecomment-2031615530
You are receiving this because you are
These are common needs and the query is not exactly obvious, so why not.
Hijack the otherwise unused poltest.spec for the sources test, its the
only multi-source spec we have. Only, it hasnt been parseable in about ten
years because of the Collections: tag, so remove that...
You can view,
@pmatilai commented on this pull request.
> +[0],
+[hello-1.0-1
+],
+[])
+RPMTEST_CLEANUP
+
+AT_SETUP([rpmspec -q --srpm])
+AT_KEYWORDS([query])
+RPMTEST_CHECK([
+RPMDB_INIT
+runroot rpmspec --srpm \
+ -q /data/SPECS/hello.spec
+],
+[0],
+[hello-1.0-1.src
+],
I'd put this in the same
Oh and, thanks @signed-log for reporting!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3001#issuecomment-2031692954
You are receiving this because you are subscribed to this thread.
Message ID:
rpmvs.c is the only one using it in the rpm source and it can be trivially
rewritten.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3013
-- Commit Summary --
* Get rid of pgpGrab()
-- File Changes --
M
@pmatilai pushed 1 commit.
cb47d1e144cb0e83c715086423785c03f0ec51c4 Populate RPMTAG_SOURCERPM early to
allow binaries to be identified
--
View it on GitHub:
@pmatilai pushed 1 commit.
f824484589b8260a59dab0265fe41901c399a4c6 Ensure binary pkg headers are
identified as such after a spec parse
--
View it on GitHub:
When you run rpmbuild directly I would argue that you do not care about
security already :) I guess it will be hard for rpmbuild to handle remounts for
you. While it is no brainer for Mock.
What mock will need to have in rpm implemented is:
1) rpmbuild -ba --nocheck foo.spec # this already
Yeah, I've always been afraid of broaching the idea seriously. I had joked
about this with @ffesti a few times at the openSUSE Conference, but I'm really
glad to see us doing this.
--
Reply to this email directly or view it on GitHub:
Aaargh, except that the issue here was not positively identifying source
headers but binaries :facepalm:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2995#issuecomment-2031869298
You are receiving this because you are subscribed to
Note that pgpGrab() is in the public API. I could not find any usage outside of
rpm, though.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3013#issuecomment-2031922210
You are receiving this because you are subscribed to this thread.
> I'd like to be able to query a spec file for the list of its patches.
`rpmspec --srpm -q --qf "[%{PATCH}\n]" `
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8980564
You are receiving this because you
I think the original intend was to make the macro definitions look like bash
function definitions.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2976#issuecomment-2031386866
You are receiving this because you are subscribed to this
An idea was floated on fedora-devel to remove tests from packages altogether. I
empathetically disagree with that, but maybe it'd be useful to "sandbox" the
tests a bit. The test code is often of lesser quality and less reviewed.
The basic idea is to make sure that the `%check` section
Yeah, that's also what I was going to implement. The userid seems to be
optional.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3001#issuecomment-2031710562
You are receiving this because you are subscribed to this thread.
Message
Heh, so a more careful reading of the report... the userid is *intentionally*
removed here.
So assuming that's a reasonable thing to do (considering where these keys are
coming from), the minimal fix would probably be this instead:
```
- digps[count]->userid =
Added a second commit there to deal with RPMTAG_SOURCERPM too:
https://github.com/rpm-software-management/rpm/pull/3012/commits/cb47d1e144cb0e83c715086423785c03f0ec51c4
--
Reply to this email directly or view it on GitHub:
Right, I remember coming across this and thinking about removing and then
postponing for whatever reason, and here we are. The positive thing is that
while it's in the API, it's not in the ABI, so we can remove without soname
bumps. Indeed nobody should be using it, and by the looks of things
Merged #3013 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3013#event-12326180710
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@pmatilai pushed 2 commits.
2831368e2b7858047e9668ef126034faf6215dce Ensure source headers are identified
as such after a spec parse
e5184ba0ad9149e72c2f076f618053157927c4b9 Ensure binary pkg headers are
identified as such after a spec parse
--
View it on GitHub:
41 matches
Mail list logo
