Making remote execution (cross-compilation) easier added (inspired by
https://github.com/rpm-software-management/rpm/discussions/2884)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2078#issuecomment-1928947972
You are receiving this
Oh. Reading more carefully now, I can see a lack of "the" and a relevant plural
in "running test suites" :sweat_smile: Adjusted the title to make it clear.
All the build scriptlets have (some) support for remote execution through this:
> %___build_cmd %{?_sudo:%{_sudo}
@pmatilai I was referring to `%check` in spec files, _not_ RPM’s own test suite
(though that would be useful too).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2884#discussioncomment-8374826
You are receiving this because you
I confirmed that this still builds on macOS, using [these
commands](https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1877296382)–the
only difference being that I added `readline` to `PKG_CONFIG_PATH` like this:
Just found in inbox that another maintainer sorted out issue related to create
directory in python module source tree
https://github.com/PyGithub/PyGithub/pull/2894. As you see fixing that it is
not rocket science ..
--
Reply to this email directly or view it on GitHub:
Just made grep across all Fedora spec files
```console
[tkloczko@pers-jacek SPECS.fedora]$ grep SPECPARTS *
python-bidict.spec:# SPECPARTS dir in %%_builddir/%%buildsubdir is leaking to
setuptools package
python-bidict.spec:rm -rf SPECPARTS
python-cairocffi.spec:- Drop rmdir SPECPARTS
> Do I understand correctly that the `BUILDROOT` dir was replaced by
> `%{_builddir}/%{_target_cpu}-%{_target_os}-root`? The `%{_builddir}` is the
> right move IMHO, but what is the advantage of
> `%{_target_cpu}-%{_target_os}-root` over `BUILDROOT`, especially when e.g.
> `SPECPARTS` stays
I am not sure if tying this to the `%setup` is useful, unless there is also
some alternative to setup this independently. Maybe if the `%{-s}` also
accepted some alternative build name(s).
> A one gotcha here is that special %doc and %license has traditionally worked
> for both built and
Do I understand correctly that the `BUILDROOT` dir was replaced by
`%{_builddir}/%{_target_cpu}-%{_target_os}-root`? The `%{_builddir}` is the
right move IMHO, but what is the advantage of
`%{_target_cpu}-%{_target_os}-root` over `BUILDROOT`, especially when e.g.
`SPECPARTS` stays the same.
> > > You are also kinda confused about RPMs and SRPMs.
> >
> >
> > I don't think I am. Or at least I don't know why you think so.
>
> That's what a confused person would say...
:rofl: :man_facepalming: 路
> Merging RPMs and SRPMs is not something we will pursue and it doesn't make
> any
> * [Print full path if file removal fails
> #2806](https://github.com/rpm-software-management/rpm/pull/2806)
Just FTR, this one already is in 4.19.1.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2878#issuecomment-1927097817
You
This is a small bugfix-only update addressing a number of regressions and other
issues. A changelog preview follows:
Fixes
* *Packaging:* Dont warn about missing user/group on skipped files
supRegression/sup
([#2814](https://github.com/rpm-software-management/rpm/pull/2814))
*
> Steps to reproduce:
>
>package gcc: version 1.1
>package hello: BuildDepends gcc; changelog epoch 1; but its build script
> includes SOURCE_DATE_EPOCH in the binary
>build package hello
>update package gcc to version 1.2
>[...]
I get that this is the real-world scenario,
> > You are also kinda confused about RPMs and SRPMs.
>
> I don't think I am. Or at least I don't know why you think so.
That's what a confused person would say...
Merging RPMs and SRPMs is not something we will pursue and it doesn't make any
sense. There is no point in merging SRPMs as they
@dmnks feel free to correct/extend, but the test-suite does run as a separate
step in the "native" mode using already built binaries. That's only supported
on Fedora at the moment but that's AIUI just a matter of somebody adding +
maintaining a native dockerfile for their target distro.
--
> You are also kinda confused about RPMs and SRPMs.
I don't think I am. Or at least I don't know why you think so.
One possibility I can think of is that if the RPMs should be mergeable, then
probably also SRPM should be mergeable for consistency? That would be likely
weird, not sure 路
> I
Even longer answer: One could create a tool to do that with the rpm API. But I
really don't see a a reason to do so. You are also kinda confused about RPMs
and SRPMs. I don't think you really want to merge binary RPMs but get rid of
packages in distgit - which is the expensive part as far as I
Short answer: No
Longer answer: No, but one could create one, but you really do not want to.
Other answer: Yes, but no the way you want.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8368857
You are
FWIW, the %{NAME}-%{VERSION}-PKG name is not really intended as final, I used
that just to have it stand out from the logs. Better ideas welcome.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1926715511
You are
Besides PoC, this is of course rather simple-minded too. There may be some
interesting possibilities in supporting multiple build variants natively here.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1926707782
You
@pmatilai pushed 1 commit.
80a60aa2bddb78a897e6279891ec58d862d92d74 fixup! Introduce an rpm-controlled
per-build directory
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885/files/2e18582771df083726278bc64feee8b8b5268e74..80a60aa2bddb78a897e6279891ec58d862d92d74
This is related to
https://github.com/rpm-software-management/rpm/discussions/2849#discussioncomment-8368400.
Given there are a.rpm and b.rpm packages, is there a way to merge them into
package c.rpm (or merge b.rpm into a.rpm, it does not matter).
--
Reply to this email directly or view it
This is on top of the per-build directory PR because it makes this much easier
to do, ie the actual feature here is just the last commit.
This is NOT meant for merging at this point, just that even a crude
implementation is easier to discuss than thin air. See also
Just FTR, this is related to the #2847.
What I am possibly about to do is to package Ruby with a few gems into single
binary RPM. So my high level idea is to essentially "join" Ruby .spec file with
the .spec files of the gems.
--
Reply to this email directly or view it on GitHub:
> Append/prepend is still operating on exactly one script of a type.
Maybe it could stay like that in practice, if you are talking about the
underlying bash script (which to me is just implementation detail I
deliberately ignore)
> With append/prepend, you can place sub-package specific build
Add a new %setup switch -s to indicate building in a directory outside the
source directory, known as vpath build in some circles. Add a new
%{sourcesubdir} macro which by default equals %{buildsubdir}, but when -s is
used, we create and switch to a separate directory after unpacking.
A one
@pmatilai pushed 2 commits.
beeb017d5f471aa5572f5c18365ece89cce8ebd0 Make buildroot fully rpm controlled,
always inside the per-build directory
2e18582771df083726278bc64feee8b8b5268e74 Move SPECPARTS to per-pkg builddir,
no longer needing name-version
--
View it on GitHub:
In our ancient wacko setup, %_builddir is shared by all your packages, under
which a package may create %buildsubdir - if it uses %setup that is. In other
words, theres no safe and sane place for rpm to place per-build material.
Introduce a new intermediate directory between the two, created in
Good point wrt multiple build directories :+1: While we have native support for
these kind of multiple variants builds via `RemovePathPostfixes` (which isn't
used by vim or python in fedora, curl does though), having separate build and
buildroot directories could make that easier to use.
--
Append/prepend is still operating on exactly one script of a type. Adding
support for multiple scripts for each step would be a huge amount of work for
very little benefit, I don't see that happening. With append/prepend, you can
place sub-package specific build scriptlet sections into their
30 matches
Mail list logo
