We never *supported* relative %_builddir and whatnot, that they happened to
work in some cases was more like a lucky incident.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3128#issuecomment-2134386038
You are receiving this because
This looks a lot like the output of `dnf up`. Are you sure you are in the right
repository?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3129#discussioncomment-9572960
You are receiving this because you are subscribed to this th
Make `rpm up` show the the current installed version between the Architecture
and Version columns below.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softw
Just for completeness, this issue was found thanks to the following test:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/tests/auto-set-build-flags/runtest.sh
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3128#issu
Thinking about it again, the word "sane" perhaps isn't entirely right, this
actually isn't desired :smile: Even though we don't claim for `$RPM_BUILD_ROOT`
to be an *absolute* path, it kinda makes sense for it to be, or we shouldn't at
least regress here...
--
Reply to this email directly or
If `%_builddir` is a relative path configured externally (e.g. `.`), when we
internally override it with the newly created per-package subdirectory, it's
still a relative path (e.g. `./test-1-build`). That, in turn, ends up in
`$RPM_BUILD_ROOT` at build scriptlet execution time which is initiali
It happens here if I `mock --rebuild any.src.rpm`, nothing special required.
Probably koji detects noarch packages and then puts forcearch into the config
or something.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-
thank you for your insightful reply and the hint for how to fix
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3126#issuecomment-2133613148
You are receiving this because you are subscribed to this thread.
Message ID: _
Oh, thanks but I actually meant a reproducer use-case or such but okay I can
reproduce now.
It's pretty weird because under koji, the --target is noarch in mock as it
should (eg
https://kojipkgs.fedoraproject.org//packages/python-pluggy/1.3.0/3.fc40/data/logs/noarch/build.log)
but locally it se
https://github.com/rpm-software-management/mock/blob/3560d386d32e0d96e50f1495a0ee66c0e9d3fe55/mock/py/mockbuild/backend.py#L744
https://github.com/rpm-software-management/mock/blob/3560d386d32e0d96e50f1495a0ee66c0e9d3fe55/mock/py/mockbuild/backend.py#L43
https://github.com/rpm-software-management
@mlschroe commented on this pull request.
> @@ -229,6 +229,28 @@ char * rpmPubkeyBase64(rpmPubkey key)
return enc;
}
+rpmRC rpmPubkeyMerge(rpmPubkey oldkey, rpmPubkey newkey, rpmPubkey *mergedkeyp)
+{
+rpmPubkey mergedkey = NULL;
+uint8_t *mergedpkt = NULL;
+size_t mergedpktl
Can you point me to a case where it does that?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-2133382647
You are receiving this because you are subscribed to this thread.
Message ID: __
I agree that `rpmbuild -bb --target x86_64 noarch.spec` is nonsense, but (at
least here, and I don't see anything too unusual in the config) mock does that.
Probably best to just not make mock pass --target unless it's crosscompiling.
--
Reply to this email directly or view it on GitHub:
https:/
Merged #3127 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3127#event-12944517573
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Since 9165963de8bb5d5ad0a24ea4656d6d04d733f6bc, the main header wasn't
getting properly filled on plain src.rpm build modes like -bs. So a lot of
things was missing, but spotted in particular because %packager wasn't
getting set as per macros in Koji. Fix by letting rpm finalize the spec after
Thinking along these lines, we could maybe use `Patch(): foo.patch`
syntax for independent patches, and `%patchlist -k ` for patchlists.
Then this basically becomes just a one thing to store alongside the patch
itself.
--
Reply to this email directly or view it on GitHub:
https://github.com/r
@pmatilai Thank you for working on this!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-213286
You are receiving this because you are subscribed to this thread.
Message ID:
Oh absolutely. The default behavior of %autosetup should be some "just make it
so" thing, but underneath itm a -k(eyword) argument to %autopatch seems like a
nice way to achieve it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3110#
There have indeed been quite a few improvements to mkosi lately so I understand
that it might not have been suitable when you were working on this.
Note that when it comes to building cross building, we have CI in mkosi that
verifies that verifies that mkosi can do cross distribution image build
I mean, I know mock always passes --target, and that's been the right thing to
do (and still isn't wrong, it's just no longer strictly needed). But it passes
--target noarch when building noarch packages, and --target normally.
--
Reply to this email directly or view it on GitHub:
https://gith
We'll need to better document this change.
In the meanwhile, packages will have to adapt. The current behavior is the
right one from package's POV, ie a noarch package must be buildable with
'--target noarch', and anything else is basically a packaging bug *somewhere*.
Only, rpm doesn't offer v
That's indeed the very same issue: the host tooling is wherever, but noarch
%_libdir is always /usr/lib.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3126#issuecomment-2132795819
You are receiving this because you are subscribed to
22 matches
Mail list logo
