And that all depends on what exact package and version we're talking about. I
assume current Fedora rawhide from the context, but the packaging has evolved
quite a bit over time.
In the rawhide rpm, 'rpm-libs' is supposed to be "GPL or LGPL" and the rest
just GPL. Except maybe 'rpm-devel', wher
Fixes https://github.com/rpm-software-management/rpm/issues/2532
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2533
-- Commit Summary --
* Rename SPECPARTS to .SPECPARTS to make it less disruptive
-- File Changes --
The problem with this is that the directory was intentionally made LOUD because
the feature is quite implicit otherwise, yet there's lots of magic going on
behind the scenes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2533#issuecomm
An easy solution would be letting a package override the path. That allows the
handful of special cases to handle it on spec level while leaving it loud and
clear for the others. Those overriding it are obviously aware of the magic it
entails so that's not a problem.
Currently the macro thing i
Repeating this here to attach it to the issue rather than a specific PR:
An easy solution would be letting a package override the path. That allows the
handful of special cases to handle it on spec level while leaving it loud and
clear for the others. Those overriding it are obviously aware of t
> An easy solution would be letting a package override the path. That allows
> the handful of special cases to handle it on spec level while leaving it loud
> and clear for the others...
What would b the advice for packages affected by the setuptools package
discovery issue? Putting `%global sp
I wonder if we could make it the default value for now (i.e. in the spirit of
#2533 basically)?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2532#issuecomment-1580266258
You are receiving this because you are subscribed to this threa
In our testing Copr for Python 3.12, the `r"Multiple top-level packages
discovered in a flat-layout: \[.*'SPECPARTS'"` regex was found in:
- python-uc-micro-py
- python-linkify-it-py
- python-nose2
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manageme
so it can be configured from the spec file
Also move the dir beside the %buildsubdir as %{buildsubdir}-SPECPARTS so it
doesn't pollute the %buildsubdir.
This patch is still missing adjustments to the dynamic_specs.md as we might
decide to keep the SPECPARTS in %buildsubdir
You can view, comment
I don't know. Three affected packages is a handful that where a workaround
seems acceptable, if it's dozens of packages then less so. Unless it could be
hidden in the surrounding helper macros.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/
Replaces: #2533
Resolves: #2532
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2534#issuecomment-1580614313
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rp
#2534 would solve that issue by moving the SPECPARTS dir one dir up. It's only
one char different for moving it back in. But so far I don't quite see a
drawback for doing it this way except there is now one more way how builds of
the same package can step on each others toe.
--
Reply to this e
> I remember people were using `BuildRequires(check)` until this syntax was
> prohibited (this might be hint for BZ query smile)
Found it,
* [Bug 1134397](https://bugzilla.redhat.com/show_bug.cgi?id=1134397) - RFE:
%check-only requirements specification
* [Bug 1394870](https://bugzilla.redhat.c
> Three affected packages is a handful where a workaround seems acceptable, if
> it's dozens of packages then less so.
"Automatic discovery" in setuptools is quite new
([v61.0.0](https://setuptools.pypa.io/en/latest/history.html#v61-0-0), 24 Mar
2022) and still in beta; that's probably why so f
We've rpm.i686 installed in a chroot on an Icelake host.
And on trying to install a `x86_64` rpm with `setarch x86_64 rpm -i` we're
getting a `is intended for a different architecture` error.
```
# setarch x86_64 rpm -i glibc.x86_64.rpm nss-softokn-freebl.x86_64.rpm
warning: nss-softokn-freebl.x8
The code to autodetect x86 CPU model runs the cpuid instruction after setting
up 1 in eax. This gives the processor signature back in eax which encodes the
model number.
As per Intel Application Note 485 and AMD publication #25481, when deriving
model, we should look at both the base model in e
@ffesti pushed 1 commit.
ac37764891a8d832427f057064610b07ca0dbf52 Add RPM_LD_FLAGS to build environment
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2481/files/ee3cb5002f9aedfd987983f12016c3d31d8dab8a..ac37764891a8d832427f057064610b07ca0dbf52
You are receiving this
To be honest I have no idea why rpm source tree still cares about $RPM_*FLAGS
env variables.
%configiure, %cmake and %meson are using %set_build_flags and that macro has
nothing to do with $RPM_*_FLAGS.
If it something still uses $RPM_*FLAGS it is still some rare uncleaned case.
--
Reply to th
Right, that's another way to deal with it. Having an extra directory seems a
bit messy but then it'd be just temporary thing until (and further motivation
for) #2078 .
It does add an unconditional dependency on using a buildsubdir (and so,
%setup), but that's not necessarily a bad thing at all
@pmatilai commented on this pull request.
> @@ -132,6 +132,8 @@
%_keyringpath %{_dbpath}/pubkeys/
+%specpartsdir %{_builddir}/%{buildsubdir}-SPECPARTS
Move this next to the other build directory stuff, _specdir and buildroot and
whatnot.
--
Reply to this email directly or view
It's of course not actually introduced in this patch, but I have to say the
`%specpartsdir` macro name continues to look odd without a leading underscore.
But probably that's just from years of conditioning from exposure to the weird
underscorey names :laughing:
--
Reply to this email direct
@ffesti's proposal is probably the least painful way out for now: it avoids
polluting specs with crap that would become obsolete with #2078.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2532#issuecomment-1581977224
You are receiving
@hroncok commented on this pull request.
> @@ -132,6 +132,8 @@
%_keyringpath %{_dbpath}/pubkeys/
+%specpartsdir %{_builddir}/%{buildsubdir}-SPECPARTS
Is buildsubdir always defined?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/r
23 matches
Mail list logo
