Fixes
python/header-py.c:744:2: error: incompatible function pointer types
initializing 'hashfunc' (aka 'int (*)(struct _object *)') with
an expression of type 'long (PyObject *)' (aka 'long (struct
_object *)') [-Wincompatible-function-pointer-types]
| hdr_hash, /*
Fixes
python/header-py.c:744:2: error: incompatible function pointer types
initializing 'hashfunc' (aka 'int (*)(struct _object *)') with
an expression of type 'long (PyObject *)' (aka 'long (struct
_object *)') [-Wincompatible-function-pointer-types]
| hdr_hash, /*
I needed to compile my own rpm with `--with-lua` support as my system
(slackware) ships with rpm configured with the `--without-lua-support` flag.
However, the Lua that my system provides (actually slackbuilds.org provides) is
version 5.1.5, but the `--with-lua-support` flag requires at least ve
> Are you subscribed to the Fedora devel list?
Oh. Yes, I'm subscribed there, so by "other distro folks" I meant non-Fedora
people :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1453269105
You are receiving th
I am confused by the nomenclature here. As a spec author, when I write:
```
%bcond tests 1
```
I expect the tests will run.
Now the distro maintainer (or anybody who can define macros, really) can define
a macro:
```
%bcond_default_tests 0
```
What happens to my package? Does it no longer run
> What about padding between one tag and the next?
See above, "you'll have an explicit requirement for *all* padding to be zeros
in v6" (emphasis added)
> That said, the current solution is simpler and much more obvious from the
> perspective of package reading.
In some ways yeah, but the pad
Is putting something like `%bcond foo 0%{?default_foo}` in the spec file not an
option?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1453186692
You are receiving this because you are subscribed to this thread.
Messag
Makes sense, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2406#issuecomment-1453149586
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mail
> I was also wondering if we shouldn't have done a soname bump before 4.18.0
> due to the following commits which have changed or removed some public
> interfaces
Those interfaces are not considered public, even if the symbols may be visible
in the DSOs. The rpm criteria for a public interface
Nice. This is certainly a common need, I've seen activity around this topic on
Fedora/RHEL side as well but I've lost track as to where those efforts are now.
Tagging @hroncok and @encukou for past interest in this area.
--
Reply to this email directly or view it on GitHub:
https://github.com/r
10 matches
Mail list logo
