Re: [Rpm-maint] [rpm-software-management/rpm] RFE: watermark short-circuit'ed binaries (Issue #3091)
If they can affect the build, they can do it even in -ba. If rpm wants to guarantee its own operations, it should provide an API for the caller to handle %generate_buildrequires installations (e.g. via file sockets or pipes or whatever). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136645805 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: watermark short-circuit'ed binaries (Issue #3091)
Mock guarantees the "production readiness" and "reproducibility" of the result. Running the final -ba without noprep would gain no benefit to mock. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136608224 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %_enable_debug_packages can cause debuginfo on noarch packages (Issue #3115)
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/mock/blob/3560d386d32e0d96e50f1495a0ee66c0e9d3fe55/mock/py/mockbuild/config.py#L264 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-2133512058 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
>From @pmatilai at #3121: > I can see why mock would use such a thing, but I'm not really comfortable > with that (or the option itself) because it seems that mock is now driving > the build and not rpmbuild. And this means any changes to rpmbuild are even > more difficult than they are otherwise. Where would be the best place to discuss this further? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126599733 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] The --noprep option executes %mkbuilddir which breaks %generate_buildrequires in Mock (Issue #3120)
> You need [Mock > v5.3+](https://rpm-software-management.github.io/mock/Release-Notes-5.3) that > has this optimization. Even before that, `--noprep` was used for the last rpmbuild round, so I assume even older mock would be impacted. > (not yet build in Rawhide, or already untagged, not sure). Not yet built. It was built in Python 3.13 copr when pushed to distgit. In the meantime, I have removed the build. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3120#issuecomment-2124916142 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
**Describe the bug**
RPM 4.20 breaks all Fedora packages with %generate_buildrequires (when built in
mock, koji, etc.).
The error looks like this:
```
Executing(%generate_buildrequires): /bin/sh -e /var/tmp/rpm-tmp.nQJoQh
+ umask 022
+ cd /builddir/build/BUILD/python-cffi-1.16.0-build
+ cd cffi-1.16.0
/var/tmp/rpm-tmp.nQJoQh: line 34: cd: cffi-1.16.0: No such file or directory
```
**To Reproduce**
Steps to reproduce the behavior:
```
mock -r fedora-rawhide-x86_64 --addrepo
'https://download.copr.fedorainfracloud.org/results/pmatilai/rpm-snapshot/fedora-rawhide-$basearch/'
init
mock -r fedora-rawhide-x86_64 --addrepo
'https://download.copr.fedorainfracloud.org/results/pmatilai/rpm-snapshot/fedora-rawhide-$basearch/'
--update
mock --verbose -r fedora-rawhide-x86_64 --addrepo
'https://download.copr.fedorainfracloud.org/results/pmatilai/rpm-snapshot/fedora-rawhide-$basearch/'
-Nn python-cffi-1.16.0-4.fc41.src.rpm
```
`python-cffi-1.16.0-4.fc41.src.rpm ` was generated from the Fedora Rawhide
package by `fedpkg srpm`, no changes.
**Expected behavior**
The build should work, as it did with RPM 4.19.
**Output**
```
...
DEBUG: Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M',
'903169f1656745f3a76286ffeebf52ee', '-D',
'/var/lib/mock/fedora-rawhide-x86_64/root', '-a', '-u', 'mockbuild',
'--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.not1p4a8:/etc/resolv.conf',
'--bind=/dev/btrfs-control', '--bind=/dev/mapper/control', '--bind=/dev/fuse',
'--bind=/dev/loop-control', '--bind=/dev/loop0', '--bind=/dev/loop1',
'--bind=/dev/loop2', '--bind=/dev/loop3', '--bind=/dev/loop4',
'--bind=/dev/loop5', '--bind=/dev/loop6', '--bind=/dev/loop7',
'--bind=/dev/loop8', '--bind=/dev/loop9', '--bind=/dev/loop10',
'--bind=/dev/loop11', '--console=pipe', '--setenv=TERM=vt100',
'--setenv=SHELL=/bin/bash', '--setenv=HOME=/builddir',
'--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin',
'--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"',
'--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=C.UTF-8',
'--resolv-conf=off', 'bash', '--login', '-c', '/usr/bin/rpmbuild -br --noprep
--noclean --target x86_64 --nodeps /builddir/build/SPECS/python-cffi.spec']
with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir',
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND':
'printf "\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ',
'LANG': 'C.UTF-8', 'SYSTEMD_NSPAWN_TMPFS_TMP': '0', 'SYSTEMD_SECCOMP': '0'} and
shell False
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE_EPOCH=1706227200
Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.rsmzU0
+ umask 022
+ cd /builddir/build/BUILD/python-cffi-1.16.0-build
+ test -d /builddir/build/BUILD/python-cffi-1.16.0-build
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w
/builddir/build/BUILD/python-cffi-1.16.0-build
+ /usr/bin/rm -rf /builddir/build/BUILD/python-cffi-1.16.0-build
+ /usr/bin/mkdir -p /builddir/build/BUILD/python-cffi-1.16.0-build
+ /usr/bin/mkdir -p /builddir/build/BUILD/python-cffi-1.16.0-build/SPECPARTS
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%generate_buildrequires): /bin/sh -e /var/tmp/rpm-tmp.wyDFnL
+ umask 022
+ cd /builddir/build/BUILD/python-cffi-1.16.0-build
+ cd cffi-1.16.0
```
**Environment**
- OS / Distribution: Fedora 41
- Version: rpm-5.99.90-0.git16959.1.fc41 (also with 4.19.91-1.fc41 from Fedora
distgit)
**Additional context**
Mock pretty much does this:
```
rpmbuild -br --noclean
rpmbuild -br --noprep --noclean (REPEAT UNTIL GOOD)
rpmbuild -ba --noprep
```
But the new `%mkbuilddir` section `rm`s the prepped sources:
```
Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.rsmzU0
...
+ /usr/bin/rm -rf /builddir/build/BUILD/python-cffi-1.16.0-build
```
Hence, `--noprep` does not work the way it did (mock assumes sources are
already prepped by the previous rpmbuild round).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3121
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
Is there anything I need to do to initiate a backport to 4.19.x? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2076977118 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix multiply defined local macros escaping scope (PR #3059)
Thank you! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3059#issuecomment-2074482274 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
Saner handling of multiple identical options would be nice, but even without that, the described behavior is wrong. Agreed? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2072404151 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
**Describe the bug**
Consider this situation:
Macros:
```
%macro_leaking(E:) %{nil}
%macro_infected(E:) echo -- "%{-E:-E was provided: %{-E*}}%{!-E:there was no
-E}"
```
Notice both macros take an `-E` option with a value. The exact name of that
option is not limited to `E`.
And run:
```
%macro_leaking -E myEoption1 -E myEoption2
%macro_infected
%macro_infected
%macro_infected
```
Results in:
```
echo -- "-E was provided: myEoption1"
echo -- "there was no -E"
echo -- "there was no -E"
```
See that the value passed to `-E` leaks to the infected macro. Moreover:
```
%macro_leaking -E myEoption1 -E myEoption2 -E myEoption3 -E myEoption4
%macro_infected
%macro_infected
%macro_infected
%macro_infected
```
Leads to:
```
echo -- "-E was provided: myEoption3"
echo -- "-E was provided: myEoption2"
echo -- "-E was provided: myEoption1"
echo -- "there was no -E"
```
The leaking and infected macros can even be the same:
```
%macro_infected -E myEoption1 -E myEoption2 -E myEoption3 -E myEoption4
%macro_infected
%macro_infected
%macro_infected
%macro_infected
```
Leads to:
```
echo -- "-E was provided: myEoption4"
echo -- "-E was provided: myEoption3"
echo -- "-E was provided: myEoption2"
echo -- "-E was provided: myEoption1"
echo -- "there was no -E"
```
**To Reproduce**
Spec:
```
Name: reproducer-eee
Version:0
Release:0
Summary:...
License:...
%description
...
%define macro_leaking(E:) %{nil}
%define macro_infected(E:) echo -- "%{-E:-E was provided: %{-E*}}%{!-E:there
was no -E}"
%macro_leaking -E myEoption1 -E myEoption2
%macro_infected
%macro_infected
%macro_infected
```
Run `rpmspec -P reproducer-eee.spec`.
---
This impacts macros in Fedora. When I run:
```
%check
%pyproject_check_import -e '*django*' -e '*flask*' -e '*httpx*' -e '*requests*'
-e '*sqla*' -e '*starlette*'
%tox
```
The `%tox` macro will receive one of the `-e` values (coincidentally, `%tox`
also uses `-e` for one of its options).
**Expected behavior**
Passing option values multiple times should never leak to other macro calls.
**Environment**
- OS / Distribution: Fedora 39, 41
- Version rpm-4.19.1.1-1.fc39, rpm-4.19.1.1-1.fc40
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Should the License of a debugsource package be inherrited from SourceLicense tag? (Discussion #3035)
I wonder if the License of the generated debugsource package should be derived from the SourceLicense tag or not. Do we assume the debugsource package contains sources, hence it is covered by SourceLicense, or do we assume it only contains sources of stuff that has been built, and hence should not inherit SourceLicense? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3035 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
That's currently possible and can lead to various subtle runtime failures instead. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035405478 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make -C the default for BuildOption(prep) (Issue #2998)
Thanks. I noticed the `BuildOption(prep)` documentation was not updated in that PR. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034393793 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Understanding of the Declarative builds, Python edition (Discussion #2997)
https://github.com/rpm-software-management/rpm/issues/2998 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8919866 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make -C the default for BuildOption(prep) (Issue #2998)
See https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8915180 It would make sense to make `-C` the default option for `BuildOption(prep)`, so packages utilizing the Declarative builds feature don't have to pass custom `-n` to it. (Using custom `-n` is also used as an example in the documentation for `BuildOption(prep)`, so that will need a different example.) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2998 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Understanding of the Declarative builds, Python edition (Discussion #2997)
Should I open an issue for -C to be the default for BuildOption(prep)? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8916583 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Understanding of the Declarative builds, Python edition (Discussion #2997)
As long as it won't tell me `Unknown option l in buildsystem_pyproject_install` but let me pass any option further down via `%**`, good (even better, so I won't have to duplicate the option list). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8915205 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Understanding of the Declarative builds, Python edition (Discussion #2997)
Hello. I've just located
https://github.com/rpm-software-management/rpm/issues/1087 in
https://fedoraproject.org/wiki/Changes/RPM-4.20 and I've read
https://rpm-software-management.github.io/rpm/manual/buildsystem.html
I am trying to understand how to use this, so let's dive in.
Suppose I currently have this specfile simplified from
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_example_spec_file
```spec
Name: python-pello
Version: 1.0.4
Release: 1%{?dist}
Summary: Example Python library
License: MIT-0
URL: https://github.com/fedora-python/Pello
Source: %{url}/archive/v%{version}/Pello-%{version}.tar.gz
BuildArch:noarch
%description
...
%package -n python3-pello
Summary: %{summary}
Recommends: python3-pello+color
%description -n python3-pello
...
%pyproject_extras_subpkg -n python3-pello color
%prep
%autosetup -p1 -n Pello-%{version}
%generate_buildrequires
%pyproject_buildrequires -t
%build
%pyproject_wheel
%install
%pyproject_install
%pyproject_save_files -l pello
%check
%pyproject_check_import
%tox
%files -n python3-pello -f %{pyproject_files}
%doc README.md
%{_bindir}/pello_greeting
%changelog
```
---
If I defined the following macros (in any macro file?):
```spec
%buildsystem_pyproject_generate_buildrequires(rRxtNwe:C:)
%pyproject_buildrequires %**
%buildsystem_pyproject_build(C:) %pyproject_wheel %**
%buildsystem_pyproject_install(l) %pyproject_install %["%**" == "" ? "" : "\
%pyproject_save_files %**"]
%buildsystem_pyproject_check(e:t) %pyproject_check_import %**
```
The spec could be simplified as such:
```spec
Name: python-pello
Version: 1.0.4
Release: 1%{?dist}
Summary: Example Python library
License: MIT-0
URL: https://github.com/fedora-python/Pello
Source: %{url}/archive/v%{version}/Pello-%{version}.tar.gz
BuildArch:noarch
BuildSystem: pyproject
BuildOption(prep):-n Pello-%{version}
BuildOption(install): -l pello
%description
...
%package -n python3-pello
Summary: %{summary}
Recommends: python3-pello+color
%description -n python3-pello
...
%pyproject_extras_subpkg -n python3-pello color
%check -a
%tox
%files -n python3-pello -f %{pyproject_files}
%doc README.md
%{_bindir}/pello_greeting
%changelog
```
Is that assumption correct?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2997
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)
It's not possible to keep them anyway. That's the problem.we want to solve: remove them when it's no longer possible to keep them. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8682257 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)
I've said it before and I will repeated it here. Dnf should gain an option to allow erasing packages iff they are no longer available in the repos. Dnf system upgarde should default to this option (at least for Fedora-provided repos). That way, we can stop manually tracking each retired package in articicial fedora-obsoletes-packages and we would not have to invent a way to "soft obsolete" packages. They would be automatically erased when they are removed from the distro AND no longer installable due to missing deps. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8682092 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow to specify a default for bcond features in a macro file (PR #2405)
@hroncok commented on this pull request.
> @@ -91,5 +91,16 @@ macros which is nicer in other situations, e.g.:
Always test for the `with`-condition, not the `without`-counterpart!
+## Overrinding Defaults
+
+For distributions it can be useful to overwrite the build conditionals on a
global scale. To not interfere with the users ability to overwrite the
conditionals on the command line there is an option to overwrite the default
value indenpendent on the one chosen in the spec file.
+
+To do this one can define a `%bcon_override_default_NAME` macro as one or zero
or use the `%{bcon_override_default NAME VALUE}` macro. Distributions can put
the former into a global macro file that is installed during local builds to
propagate these changed defaults outside their build system. Using different
versions of the macro file allows building the same set of packages in
different ways - e.g. against different libraries - without altering all the
spec files.
+
+E.g. add this in the macros file to disable support for zstd assuming this is
a common conditional in the distribution:
+```
+%bcon_override_default_zstd 0
+```
+
```suggestion
All packages with a `zstd` bcond will now build as if the bcond was defined as
`%bcond zstd 0`.
I.e. unless `--with zstd` is used, the bcond will be disabled.
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#pullrequestreview-1865033227
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow to specify a default for bcond features in a macro file (PR #2405)
Could you please add an example to the docs? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929392923 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] error: invalid version: v"3" (but only in a a complex conditional) (Issue #1883)
I suppose you care because of RHEL 9. If that's the case, I suggest you open a RHEL 9 Jira. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1883#issuecomment-1795002390 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric generators: Was "warning: Macro %1 defined but not used within scope" removed in RPM 4.17+? (Discussion #2501)
> That said, a generator not using the filename passed to it via %1 sounds > suspicious in itself. It's generating a provide based on the package name. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2501#discussioncomment-6384533 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric generators: Was "warning: Macro %1 defined but not used within scope" removed in RPM 4.17+? (Discussion #2501)
No idea? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2501#discussioncomment-6371154 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
Is a huge mess. In Fedora, we want to transition into using that, but so far it has not been a priority :( -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-1594742567 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: %{rpmversion} macro (Issue #2523)
Could you please add this to 4.19 as well? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2523#issuecomment-1587265425 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add %specpartsdir to macros.in (PR #2534)
@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/rpm/pull/2534#discussion_r1222539032
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] SPECPARTS dir in %_builddir/%buildsubdir is leaking to setuptools package discovery (Issue #2532)
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-management/rpm/issues/2532#issuecomment-1580353114 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] SPECPARTS dir in %_builddir/%buildsubdir is leaking to setuptools package discovery (Issue #2532)
> 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 specpartsdir .SPECPARTS` in the spec? Do we want dozens of specs with that? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2532#issuecomment-1580153563 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Rename SPECPARTS to .SPECPARTS to make it less disruptive (PR #2533)
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 -- M build/parsePrep.c (4) M tests/rpmspec.at (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2533.patch https://github.com/rpm-software-management/rpm/pull/2533.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2533 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] License clarification (Issue #2511)
That depends on what files are built from what source. If anything in the main package is actually built from lib or rpmio dirs, the License would be `GPL-2.0-or-later AND (GPL-2.0-or-later OR LGPL-2.1-or-later)`, based on the "no effective analysis" rule, wouldn't it? (Silly, isn't it?) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2511#issuecomment-1579903461 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] SPECPARTS dir in %_builddir/%buildsubdir is leaking to setuptools package discovery (Issue #2532)
Another Fedora package is known to be impacted. python-quantities: https://bugzilla.redhat.com/show_bug.cgi?id=2213013 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2532#issuecomment-1579523314 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] SPECPARTS dir in %_builddir/%buildsubdir is leaking to setuptools package discovery (Issue #2532)
The `SPECPARTS` directory is leaking into setuptools package discovery. When upstream Python projects choose to use automatic Python package discovery by setuptools, `SPECPARTS` is considered a Python package (because empty directories actually *are* Python packages) and when not explicitly excluded, it makes setuptools die with: ``` ... discovered packages -- ['pgactivity', 'SPECPARTS', 'pgactivity.queries'] Traceback (most recent call last): ... File "/usr/lib/python3.11/site-packages/setuptools/discovery.py", line 441, in _analyse_flat_layout return self._analyse_flat_packages() or self._analyse_flat_modules() ^ File "/usr/lib/python3.11/site-packages/setuptools/discovery.py", line 447, in _analyse_flat_packages self._ensure_no_accidental_inclusion(top_level, "packages") File "/usr/lib/python3.11/site-packages/setuptools/discovery.py", line 477, in _ensure_no_accidental_inclusion raise PackageDiscoveryError(cleandoc(msg)) setuptools.errors.PackageDiscoveryError: Multiple top-level packages discovered in a flat-layout: ['SPECPARTS', 'pgactivity']. ``` (Full traceback at https://github.com/dalibo/pg_activity/pull/378#issuecomment-1571655683) I suppose other upstreams might consider a new directory in `$PWD` something to automatically consider important. Could this directory either be moved outside of `%_builddir/%buildsubdir` or at least be hidden (e.g. `.SPECPARTS`)? Thanks -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2532 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: %{rpmversion} macro (Issue #2523)
https://github.com/rpm-software-management/rpm/pull/2256 ? Did you mean https://github.com/rpm-software-management/rpm/pull/2526 ? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2523#issuecomment-1567005064 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add %{rpmversion} builtin macro for getting the running rpm version (PR #2525)
Works: ``` sh-5.2# rpm --eval '%rpmversion' 4.18.90 ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2525#issuecomment-1566935070 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: %{rpmversion} macro (Issue #2523)
A number of % signs to escape a literal % sign in the file list. RPM 4.17 and 4.18 needed 8 of them, 4.19 is sane and only needs 2. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2523#issuecomment-1566870904 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: %{rpm_version} macro (Issue #2523)
Would it be possible to expose a macro with the version of RPM, itself? So I
could do `%if v"0%{?rpm_version}" >= v"4.19" ...`.
Thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2523
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Parametric generators: Was "warning: Macro %1 defined but not used within scope" removed in RPM 4.17+? (Discussion #2501)
Hello.
We have a workaround in our Fedora package:
https://src.fedoraproject.org/rpms/python-rpm-generators/blob/b1fa63bf02b03b2120d32eb91ca2911d4ec77beb/f/pythonname.attr#_6
While debugging a related issue on CentOS Stream 9, I figured out that the
warning is no longer present since Fedora 35.
### reproducer.spec
```
Name: reproducer
Version:0
Release:0
Summary:...
License:MIT
BuildArch: noarch
%description
...
%prep
%build
%install
mkdir -p %{buildroot}
touch %{buildroot}/xxx
%files
/xxx
```
### /usr/lib/rpm/fileattrs/xxx.attr
```
%__xxx_provides() xxx
%__xxx_path ^/
```
### rpm-4.16.1.3-1.fc34
```
$ rpmbuild -ba reproducer.spec
...
Processing files: reproducer-0-0.noarch
warning: Macro %1 defined but not used within scope
Provides: reproducer = 0-0 xxx
...
```
### rpm-4.17.1-3.fc35
```
$ rpmbuild -ba reproducer.spec
...
Processing files: reproducer-0-0.noarch
Provides: reproducer = 0-0 xxx
...
```
Was this warning removed on purpose and can we safely remove the ugly
workaround? Or is this a regression?
Looking through the relevant code's history near
https://github.com/rpm-software-management/rpm/blob/a97c376f379ee48c3b0e92e9c79f64c9fd954b64/rpmio/macro.c#L946
does not reveal any obvious intended change.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2501
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow to specify a default for bcond features in a macro file (PR #2405)
%bcond_set_libmpeg does not carry enough meaning. The other two proposals do and I don't have a preference. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1464010710 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow to specify a default for bcond features in a macro file (PR #2405)
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 tests? In my head, this isn't
called a *default*, this is an *override*.
-
A default would be this:
Distribution puts this to their macros:
```
%bcond_default_tests 1
```
A packager can now use:
```
%bcond tests
```
(Notice there is no second argument.) This means "I want this package to run
the tests when my distro desires that, but not run them if the distro does not
desire that. I explicitly let the distro decision drive my spec behavior. When
I care, I use the `--with(out)` command line option explicitly."
That I call a *default*.
(And of course, I realize this would only work for defined defaults, so when
the distro does not define a default for tests, it should fail. And if I want
to write a spec that anitcipates that possibility, I'd need to write:
```
%bcond tests 0%{?bcond_default_tests}
```
...which I can already do now anyway, as @encukou pointed out.)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1453230568
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
> Should errors encountered during fallback version lookup be a fatal error? It > sounds like the answer is yes, so I'll make those changes shortly. Note that even if the generator exists with non-zero, the build does not fail. https://github.com/rpm-software-management/rpm/issues/1183 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1420538671 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
I just want to mention that: - calling `rpm` from within a generator has always been considered a bad thing to do - `rpm -q --whatprovides` may return multiple things -- it might be safer to `rpm -qf` the actual .so file -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1407606708 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM on PyPI (Discussion #2361)
Note that if this is ready https://github.com/rpm-software-management/rpm/issues/2345 -- the rpm shim should be able to copy/link the _rpm extension module from the python3-rpm RPM package to virtual environments using different (well, probably just newer) Python versions. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2361#discussioncomment-4737301 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM on PyPI (Discussion #2361)
See also https://pypi.org/project/rpm-py-installer/ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2361#discussioncomment-4736849 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix macro scoping level on re-entry from %[] expresssion (#2354) (PR #2358)
Thank you! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2358#issuecomment-1398310035 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Using %{undefined} in expression breaks argument parsing for macros (Issue #2354)
This is a followup from https://bugzilla.redhat.com/show_bug.cgi?id=2160716
It appears that when `%{undefined ...}` or `%{defined ...}` is used in an
expression in a macro definition, it breaks parsing of options.
See e.g.
```
$ rpm --define '%xxx(r) %[ %{undefined yyy} ? "" : "" ]%{-r:the -r option was
set}%{!-r:the -r option was not set}' --eval '%xxx -r'
the -r option was not set
```
Using `%{expr: }` instead of `%[ ]` works.
```
$ rpm --define '%xxx(r) %{expr:%{undefined yyy} ? "" : ""}%{-r:the -r option
was set}%{!-r:the -r option was not set}' --eval '%xxx -r'
the -r option was set
```
While I understand `%[ ]` and `%{expr: }` behave differently, I don't
understand why parsing of macro options should be affected this way. I reckon
it is a bug.
-
The %undefine/%define macros are:
https://github.com/rpm-software-management/rpm/blob/ccfca4146d3c0c7ac3a3be37b3ea501620954d2f/macros.in#L80-L81
--
This is RPM 4.18.0.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2354
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Macro definitions expanding across multiple lines (Discussion #2353)
Hello. I often written macros defined like this:
```rpm
%py_shebang_fix %{expand:\\\
if [ -z "%{?py_shebang_flags}" ]; then
shebang_flags="-k"
else
shebang_flags="-ka%{py_shebang_flags}"
fi
%{__python} -B %{_rpmconfigdir}/redhat/pathfix.py -pni %{__python}
$shebang_flags}
```
I've abused `%expand` to have a macro definition that expands across multiple
lines.
@pmatilai [said](https://bugzilla.redhat.com/show_bug.cgi?id=2160716#c10):
> Using an outer `%{expand:...}` just to make it look like a function (as seems
> to be a common habit in Fedora) is bad thing to do because it then breaks
> when you least expect it to. NEVER use `%{expand:...}` unless you actually
> mean it, as in, need that extra expand. And even then, only use it on the
> smallest possible block to achieve what you need, not the entire thing "just
> because"
If I had to drop the `%expand`, I'd probably have to do something like:
```rpm
%py_shebang_fix \
if [ -z "%{?py_shebang_flags}" ]; then \
shebang_flags="-k" \
else \
shebang_flags="-ka%{py_shebang_flags}" \
fi \
%{__python} -B %{_rpmconfigdir}/redhat/pathfix.py -pni %{__python}
$shebang_flags
```
That is a bit **ugly**. Another option is to take a macro that is always
defined and make the thing conditional on it:
```rpm
%py_shebang_fix %{?nil:\\\
if [ -z "%{?py_shebang_flags}" ]; then
shebang_flags="-k"
else
shebang_flags="-ka%{py_shebang_flags}"
fi
%{__python} -B %{_rpmconfigdir}/redhat/pathfix.py -pni %{__python}
$shebang_flags}
```
That is **hard to understand** by the reader.
Could we get some kind of macro that allows us to achieve what we use `%expand`
for?
E.g.
```rpm
%py_shebang_fix %{multiline:\
if [ -z "%{?py_shebang_flags}" ]; then
shebang_flags="-k"
else
shebang_flags="-ka%{py_shebang_flags}"
fi
%{__python} -B %{_rpmconfigdir}/redhat/pathfix.py -pni %{__python}
$shebang_flags}
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2353
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is it %{!?foo:...} or %{?!foo:...} (Discussion #2340)
Thanks. See also https://pagure.io/packaging-committee/c/26174464286d7e44c4f5a23f71d487fd9fd4d3f9 for Fedora guidelines. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2340#discussioncomment-4631748 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Is it %{!?foo:...} or %{?!foo:...} (Discussion #2340)
At https://rpm-software-management.github.io/rpm/manual/macros.html both
variants are used:
> %{?!macro_name:value}
> %{!?with_python3:1}
Which syntax is the "proper" one? Or are both of them fully OK?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2340
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Backport %bcond macro down to 4.16 and 4.17 maintanance releases (Issue #2042)
> Enterprise distros of course do what they see fit. https://bugzilla.redhat.com/2129060 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2042#issuecomment-1254936077 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce convenient %gsub macro to wrap Lua's string.gsub() (#1764)
I like your questions but I don't have the answer. Would exposing Lua string
methods on RPM macros make sense? E.g.:
```
%{version:gsub ~} -> as if rpm.expand("%version"):gsub(rpm.expand("~"), "") is
called from Lua
%{version:gsub %{thingy} -} -> as if
rpm.expand("%version"):gsub(rpm.expand("%{thingy}"), rpm.expand("-")) is called
%{version:gsub [^w]+ - 5)} -> ...
%{whatever:len}
%{name:lower}
%{commit:sub -8}
```
> * you'd probably want to use `arg[n]` instead of `rpm.expand('%{?n})` for
> better control - for one, re-expanding the arguments tends to lead to
> %-escape hell as the arguments are already expanded once
I was aiming at compatibility with older RPM but %-escape hell seems like it is
indeed not worthy.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1764#issuecomment-908469704___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce convenient %gsub macro to wrap Lua's string.gsub() (#1764)
@hroncok pushed 1 commit. e168ef0e325097ac41d8069960a5fc07bfd28eea Introduce convenient %gsub macro to wrap Lua's string.gsub() -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1764/files/9d2d9cfb5645800a5c4b953b3fe0dd3cff70a2e3..e168ef0e325097ac41d8069960a5fc07bfd28eea ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Convenient %version without tilde macro (#1219)
See also https://github.com/rpm-software-management/rpm/pull/1764 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1219#issuecomment-906332380___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Introduce convenient %gsub macro to wrap Lua's string.gsub() (#1764)
Related to https://github.com/rpm-software-management/rpm/issues/1219 Related to https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/101 Would you accept (something like) this? It is much easier than calling Lua directly from the spec. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1764 -- Commit Summary -- * Introduce convenient %gsub macro to wrap Luas string.gsub() -- File Changes -- M macros.in (26) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1764.patch https://github.com/rpm-software-management/rpm/pull/1764.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1764 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add a rpm_macro() provides generator (#1758)
However, not sure how to load macros from a file and dump them without affecting the actual macros. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1758#issuecomment-901036513___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add a rpm_macro() provides generator (#1758)
> I'd imagine a parametric generator in Lua would work nicely for this thinking That was my plan when pitching for this functionality. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1758#issuecomment-901035261___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add a rpm_macro() provides generator (#1758)
I wonder whether "calling rpm from rpm" is considered OK nowadays. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1758#issuecomment-900999827___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] paths[with spaces and square brackets] cannot be listed in %files (#1749)
The semantics of escaping stuff in %files is not very clear. See also this thread: http://lists.rpm.org/pipermail/rpm-list/2021-June/002048.html -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1749#issuecomment-900123461___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] paths[with spaces and square brackets] cannot be listed in %files (#1749)
Consider this spec file:
```
Name: reproducer
Version:0
Release:0
Summary:...
License:MIT
BuildArch: noarch
%description
...
%prep
%install
touch '%{buildroot}/file[with spaces]'
%files
"/file[with spaces]"
```
RPM 4.16 and 4.17 will fail to build it with:
```
Processing files: reproducer-0-0.noarch
error: File not found: .../rpmbuild/BUILDROOT/reproducer-0-0.x86_64/file[with
error: Path is outside buildroot: spaces]
```
It seems that even thou the path is in `"` quotes, the spaces split it into
multiple paths.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1749___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support individual patch application in %autopatch (#1697)
> No further comments in two weeks, I guess we're sufficiently done here... Well, it was 1 day since you posted the recent update, not 2 weeks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1697#issuecomment-863942784___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support individual patch application in %autosetup (#1697)
``` %autopatch-- applies all patches defined in the spec file, in the definition order %autopatch -m 100 -- applies all patches numbered 100 or higher, in the definition order %autopatch -M 99 -- applies all patches numbered 99 or lower, in the definition order %autopatch -m 200 -M 299 -- applies all patches numbered 2xx, in the definition order %autopatch 1 -- applies patch number 1 %autopatch 4 5 2 3 6 -- applies specified patches in the order of the arguments ``` Also, I've noticed the commit message should probably say `%autopatch`, not `%autosetup` (unless `%autosetup` also supports the arguments). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1697#issuecomment-854616684___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support individual patch application in %autosetup (#1697)
So, no ranges after all? I think the documentation would benefit form some examples. I'll write some down. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1697#issuecomment-854613688___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
Fedora rawhide does not use the removed files via the rpm package. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-849506440___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
Sorry, I've meant that ranges/slices include start but not the end. I.e. `1:3` is 1, 2. Unlike `%autopatch -m 1 -M 3` which is 1, 2, 3. > Hmm, but then we can nowadays have macros opt out of option processing. Yes, but that way, no backports would be possible. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668#issuecomment-833498039___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
Note that Python ranges don't include the ending number. If you use them please keep the semantics to avoid confusion for Pythonistas. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668#issuecomment-833488732___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
I wonder if `-5` would not be recognized as an option -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668#issuecomment-833454305___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add the -n option for %autopatch (#1673)
I've grepped the source three for `autopatch` and there seem to be no documentation for the options anywhere, except the inline comment. Would you please guide me in documenting this change? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1673#issuecomment-83277___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add the -n option for %autopatch (#1673)
This allows to apply one single patch. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1673 -- Commit Summary -- * Add the -n option for %autopatch -- File Changes -- M macros.in (14) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1673.patch https://github.com/rpm-software-management/rpm/pull/1673.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1673 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
https://github.com/rpm-software-management/rpm/pull/1673 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668#issuecomment-832554477___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
I am just trying to make my life easier here, nothing more. Removals have negative impact on others :( I'll open a PR with just `%autopatch -n` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668#issuecomment-832552531___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
What about this: I'll finally shut up about `%apply_patch` if you'll take a backport of `%autopatch -n` for RPM 4.16.x and we document it as a replacement for the removal. That way, we can update our Python spec files on Fedora 33 and further and hopefully also in CentOS Stream 9. (I'd also gladly prepare downstream-only backports.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668#issuecomment-832526482___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
@hroncok pushed 1 commit. ae82e016c8ea67048ebc6db4922768eabed10a0f Add deprecated %apply_patch, provide an alternative -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668/files/d3bde71ecdd083f19ede6199d2e7ec1a25707eb5..ae82e016c8ea67048ebc6db4922768eabed10a0f ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
@hroncok pushed 1 commit. d3bde71ecdd083f19ede6199d2e7ec1a25707eb5 Add deprecated %apply_patch, provide an alternative -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668/files/31a317c32b0e7b74a54b16ffe35540623db2a5cc..d3bde71ecdd083f19ede6199d2e7ec1a25707eb5 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
@hroncok pushed 1 commit. 08a1d90e15e724d671847b3b661aa62311a38d1b Add deprecated %apply_patch, provide an alternative -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668/files/948cbc19808693de3231a4083445d2642811cc1e..08a1d90e15e724d671847b3b661aa62311a38d1b ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
@hroncok pushed 1 commit. 948cbc19808693de3231a4083445d2642811cc1e Add deprecated %apply_patch, provide an alternative -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668/files/75c9985ecc2a13e8a62cd27cf9d2826e282762d2..948cbc19808693de3231a4083445d2642811cc1e ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
@hroncok pushed 1 commit. 75c9985ecc2a13e8a62cd27cf9d2826e282762d2 Add deprecated %apply_patch, provide an alternative -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668/files/65be867de4dd62f5215f12ddd5eda5809a6e57cb..75c9985ecc2a13e8a62cd27cf9d2826e282762d2 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
@hroncok pushed 1 commit. 65be867de4dd62f5215f12ddd5eda5809a6e57cb Add deprecated %apply_patch, provide an alternative -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668/files/3935ad6c6c0309ce3295a42b7054f49c4272443e..65be867de4dd62f5215f12ddd5eda5809a6e57cb ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add deprecated %apply_patch, provide an alternative (#1668)
This is how Id deal with the removal of %apply_patch. I opened it as draft, because I have not tested the implementation yet, it also needs tests and documentation. But before I dive into that, Id like to know if this is acceptable. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1668 -- Commit Summary -- * Add deprecated %apply_patch, provide an alternative -- File Changes -- M macros.in (16) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1668.patch https://github.com/rpm-software-management/rpm/pull/1668.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1668 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pythondistdeps: Implement provides/requires for extras packages + Rework error messages (#1546)
@torsava Could you please reopen this to https://github.com/rpm-software-management/python-rpm-packaging ? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1546#issuecomment-822691189___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --eval "%{lua:rpm.interactive()}" does not immediately print the output (#1215)
Thanks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1215#issuecomment-821376174___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
I guess we are. I want to get the README adapted there but that is not a blocker for removal from here. However, let's document the transition in the changelog? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-815643913___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %exclude should not permit files to bypass check-files and be omitted from all packages built from spec (#994)
Ideas for progress: - [ ] Open a [ticket at Fedora Packaging Committee](https://pagure.io/packaging-committee/issues) or better send a PR to [File and Directory Ownership](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership) ([source](https://pagure.io/packaging-committee/blob/master/f/guidelines/modules/ROOT/pages/index.adoc#_1379)) explaining why `%exluding` files completely from packages is dangerous and not intended to work and that it MUST not be done. - [ ] Work with @voxik to change the rubygem package generator. - [ ] Work with me to solve the Python namespace package issue. For example in [this bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=1935266). Maybe `%ghosting` is a way to go. - [ ] Open a ticket on [rpmlint](https://github.com/rpm-software-management/rpmlint/) to detect completely `%exluded` files. Not sure if it is technically possible, but worth a shot. - [ ] Open a ticket on [FedoraReview](https://pagure.io/FedoraReview) to detect completely `%exluded` files. Should be possible. - [ ] In `%files`, collect the list of `%exluded` files and see if all of them are actually packages somewhere. If not, issue a warning that could be knob-ed to an error. Note that those ideas are not dependent on each other and can happen at different timelines. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/994#issuecomment-815552109___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> This could be seen as a feature: Allowing %check to examine the generated > packages Even better if %check can assert certain attributes (e.g. provides/requires) etc. are present :+1: -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814928299___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> Testing actually installed stuff can only happen from an actual installation > of that stuff, and inside rpmbuild is not really the place to do that. However it is currently the best (least worst?) place to do that. Any other solution we've been experimenting for the past 2 years is unstable, does not support multiple architectures, and suffers from usability issues. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814882229___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
Yes, I plan to rename platform.in and explain in the README what it is for. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-814831227___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
``` git clone https://github.com/rpm-software-management/rpm.git python-rpm-packaging cd python-rpm-packaging git remote remove origin git switch -c main git filter-repo --path-glob 'scripts/*python*' --path-glob 'fileattrs/*python*' --path platform.in --path COPYING --path CREDITS --force FILTER_BRANCH_SQUELCH_WARNING=1 git filter-branch -f --prune-empty --tree-filter 'sed -i "/python/!d" platform.in || :; test -s platform.in || rm -f platform.in' -- --all git remote add origin g...@github.com:rpm-software-management/python-rpm-packaging.git git push -u origin main ``` Looks good? I'll add a README and modify CREDITS accordingly later manually. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-814808384___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
Autotools are still heavily used, but they should not define standards for everything else. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814807951___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
I understand your sentiment but you are asking to change thousands of packages with no deprecation period. This is not a cool way to introduce backwards incompatible changes. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814777199___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
This just means we'll run tests in %install :/ -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814768049___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
> I'll import stuff later this week. I didn't get to it due to this week being shorter (it's a public holiday today in CZ and I am taking a break), but it is on my TODO for the next week. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-812480907___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
Keep them open, let's close them when we reopen them for the new repo. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-809296777___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
I'll import stuff later this week. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-809292477___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
I have no strong preference for either rpm-ecosystem-python or rpm-python-ecosystem -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-808276438___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
I was thinking python-rpm or rpm-python, but that that sounds like the bindings. I was thinking python-rpm-macros or python-rpm-generators, but neither of them contains the other. Hence, I though of python-rpm-ecosystem. If we do this, I can import the files there with a rebased git history. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-808229555___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
> I'm not happy about this because this is the only place where I can get all > RPM distros to pull something in and start using it. I get your point of view but I also get @pmatilai's. I guess there's no way to stop this from happening eventually and simply postponing it all the time brings us nowhere: Let's do our best to minimize the impact - by not maintaining this downstream only, but creating a distro-shared place under the @rpm-software-management GitHub org. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-808194014___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
cc @s-t-e-v-e-n-k -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-808192500___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
If this is happening, let's move it to rpm-software-management/python-rpm-ecosystem (and we'd happily maintain it there). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-808191982___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add %bcond macro for defining build conditionals (#1520)
I'd *really* like to see this happen. How can I move it forward? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1520#issuecomment-799870515___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pythondistdeps: Implement provides/requires for extras packages + Rework error messages (#1546)
Note: We should include https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/35 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1546#issuecomment-798053533___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
