Re: [Rpm-maint] [rpm-software-management/rpm] Enhance the recoverability and location of database exceptions (Issue #2828)
Nah, I am not asking to do more. I am wondering if you should do less. I am also wondering what version of RPM you are using. You can try switching to the sqlite backend, although I don't have any information about the ndb backend being less reliable. If you encounter breakage regularly there is definetely something wrong on your side. Feedback of users running hundreds of thousands machines indicate that the rpm database is very stable since we moved away from bdb. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1931458762 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 the recoverability and location of database exceptions (Issue #2828)
I'm sorry I don't have any good ideas. I just thought of backing up the database. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1931076797 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] Question about dependency between build-stage and stripping (Discussion #2805)
 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2805#discussioncomment-8386710 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] Question about dependency between build-stage and stripping (Discussion #2805)
if I include a empty build stage the binaries are stripped [rpmbuild_expat__with_build_stage_log.txt](https://github.com/rpm-software-management/rpm/files/14184852/rpmbuild_expat__with_build_stage_log.txt) [expat_with_build.spec.txt](https://github.com/rpm-software-management/rpm/files/14184877/expat_with_build.spec.txt) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2805#discussioncomment-8386684 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] Question about dependency between build-stage and stripping (Discussion #2805)
here an example output: [rpmbuild_expat_log.txt](https://github.com/rpm-software-management/rpm/files/14184807/rpmbuild_expat_log.txt) the result from this spec file: [expat.spec.txt](https://github.com/rpm-software-management/rpm/files/14184817/expat.spec.txt) The binaries are not stripped. Thank you for your help -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2805#discussioncomment-8386657 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 an rpm-controlled per-build directory (PR #2885)
@dmnks commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ", spec->buildDir, "\n",
We probably want to quote the argument to `rm -rf`, just in case 略
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#pullrequestreview-1865919592
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 an rpm-controlled per-build directory (PR #2885)
Not a fan of the `-root` suffix. Now that we have the option, why not take full advantage of directories and have a tree like this: ``` BUILD/ ├── bar-1.0 │ ├── ROOT │ │ └── x86_64-linux │ │ └── [...] │ └── SPECPARTS └── foo-1.0 ├── ROOT │ └── x86_64-linux │ └── [...] └── SPECPARTS ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1930388419 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] Question about dependency between build-stage and stripping (Discussion #2805)
The absence of the `%build` script shouldn't have any effect on whether the stripping occurs or not. In fact, the `brp-strip` script is called *after* the `%install` script. I'd suspect there to be some other reason the binaries aren't stripped for you. Can you share the `rpmbuild` output? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2805#discussioncomment-8384619 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] Clarify %_build*, %_host* and %_target* macros (Discussion #2889)
Thanks, so I'm not alone. I do wonder how it was initially intended to work, either the `--target` option is wrong or the `%configure` macro is... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2889#discussioncomment-8383850 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] Clarify %_build*, %_host* and %_target* macros (Discussion #2889)
Nobody knows. See https://github.com/rpm-software-management/rpm/issues/1650 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2889#discussioncomment-8382986 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] Proof-of-concept native support for vpath-style builds (PR #2886)
> And, -s points at the source directory when it's the build directory you'd
> like to be able to name, so it's quite backwards.
Oh, now I see. The patch actually works the opposite way then I anticipated. It
actually introduces `%{sourcesubdir}` while the `%{buildsubdir}` is actually
already existing and is the current directory for `%configure` but also `%make`
call, as it always was. This also explains the quote bellow, why you don't see
need to change the make macros.
> > BTW this does not update the `make` macros, right? Which are likely more
> > noisy then the `configure` itself. IOW on one `./configure` call, there are
> > typically two make calls, such as `make` and `make install`
>
> There's nothing to update wrt the make macros. configure, which exists in the
> _soure_ directory, generates the makefiles into the build directory, and then
> you just run make as you always did. Noisiness has nothing to do with it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1929658172
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] Pass arg2 to file trigger scripts (PR #2883)
> This is one where feedback from active packagers would be useful. Good point! I've brought it to the related discussion [thread](https://github.com/rpm-software-management/rpm/discussions/2754), let's see if we get some feedback. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2883#issuecomment-1929611264 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] file trigger quirks (Discussion #2754)
With the first argument to file triggers now implemented on master, I wonder what the semantics of the second argument, if any, should be. I've submitted a PR (#2883) adding `arg2` that has the same semantics as the regular triggers, i.e. the number of instances of the *triggering* package to remain after the operation (also described [here](https://rpm-software-management.github.io/rpm/manual/triggers.html)) but I wonder if that's actually practical. Any ideas? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2754#discussioncomment-8382780 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] Clarify %_build*, %_host* and %_target* macros (Discussion #2889)
I stumbled across an issue in relation to the %_host_* and %_target* macros
which subtly broke some builds because of armv7l/armv7hl differences. This led
me to dig into this a bit further and at this point I'm now unsure how those
macros are actually meant to be used.
macros.in says:
```
#==
# config.guess platform macros.
# Macro(s) similar to the tokens used by configure.
#
%_build %{_host}
%_build_alias %{_host_alias}
%_build_cpu %{_host_cpu}
%_build_vendor %{_host_vendor}
%_build_os %{_host_os}
%_host @host@
%_host_alias@host_alias@%{nil}
%_host_cpu @host_cpu@
%_host_vendor @host_vendor@
%_host_os @host_os@
%_target%{_host}
%_target_alias %{_host_alias}
%_target_cpu%{_host_cpu}
%_target_vendor %{_host_vendor}
%_target_os %{_host_os}
```
The `@host*@` placeholders are set to whatever CMake runs on (e.g.
`CMAKE_HOST_SYSTEM_PROCESSOR`), i.e. on what platform RPM was built on. I think
this is already wrong. In the (currently unlikely) case that RPM was cross
compiled, e.g. on an x86_64 machine to run on riscv64, @host_cpu@ and thus
`%_host_cpu` would be x86_64. What machine RPM was built on should not have any
effect on RPM though.
And then I'm confused about the role of build/host/target here. From my
understanding, having all three of them implies the toolchain semantics:
build -> where the build happens
host -> where the built binary runs on
target -> what the built binary (e.g. compiler) targets
Question remains from which PoV this is. From RPM's PoV or the .spec file's PoV?
The rpmbuild `--target` option changes which architecture the built RPMs can be
installed on and sets `%_target*` accordingly. This points to RPM's PoV. The
`%configure` macro however uses `%{_configure} --host=%{_host}
--build=%{_build}`, which means it's from the .spec file's PoV. This doesn't
match. Example:
```
> cat test.spec
Name: test
Version: 0
Release: 0
License: WTFPL
Summary: Test
%description
%build
echo %_target
set +e
%configure
touch l
%files
%license l
> rpmbuild -bb --target=i686-unknown-linux test.spec
Building target platforms: i686-unknown-linux
Building for target i686-unknown-linux
Executing(%build): /usr/bin/bash -e /var/tmp/rpm-tmp.AGeJEj
[...]
+ echo i686-linux
i686-linux
+ set +e
+ CONFIG_SHELL=/usr/bin/bash
+ export CONFIG_SHELL
+ CFLAGS='-O2 -g -m32 -march=i686 -mtune=i686 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables'
+ export CFLAGS
[...]
+ ./configure --host=x86_64-suse-linux --build=x86_64-suse-linux
--program-prefix= --disable-dependency-tracking --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info
/var/tmp/rpm-tmp.AGeJEj: line 46: ./configure: No such file or directory
+ touch l
+ RPM_EC=0
++ jobs -p
+ exit 0
Processing files: test-0-0.i686
[...]
Provides: test = 0-0 test(x86-32) = 0-0
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <=
4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/fvogt/rpmbuild/BUILDROOT/test-0-0.i386
Wrote: /home/fvogt/rpmbuild/RPMS/i686/test-0-0.i686.rpm
[...]
```
As you can see, configure was invoked to create a binary to run on
`x86_64-suse-linux` but it spat out an RPM for i686: `test-0-0.i686.rpm`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2889
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] [Feature Req] Add "IR code" itself as a rpm architecture target (Discussion #2842)
This sounds a lot like distributing software written in byte-compiled languages such as Python, which is already covered by the `noarch` target and a set of RPM macros to aid the packaging process. Typically, the `.pyc` files are shipped alongside the source code itself in the same binary package, but if they're not, CPython will generate them on the fly and place wherever in the filesystem, much like what this proposal suggests with the "lower to machine code" step. I think that's the extent to which RPM should deal with such specialized functionality. The primitives are already in place and widely used so adding support for such generic IR-code is "just" a matter of agreeing upon a mechanism on the distro level, as you suggested. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2842#discussioncomment-8382652 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] Pass arg2 to file trigger scripts (PR #2883)
Aside from those three-way indiretions making me cringe a bit (not that it makes any difference here), looks pretty straight-forward to me. This is one where feedback from active packagers would be useful. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2883#issuecomment-1929482555 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 "local_generator" (PR #2734)
@voxik commented on this pull request. > @@ -995,6 +995,25 @@ runroot rpm -qp --requires > /build/RPMS/noarch/shebang-0.1-1.noarch.rpm|grep -v ^ []) RPMTEST_CLEANUP +AT_SETUP([Local dependency generator]) +AT_KEYWORDS([build]) +RPMTEST_CHECK([ +RPMDB_INIT + +runroot rpmbuild -bb --quiet \ + --define '__local_file_attrs my_test_attr' \ If this covered multiple generators to demonstrate that something like this is supported, that would be even better -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1865093933 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 an rpm-controlled per-build directory (PR #2885)
Multiple buildroots could be useful for the the "variant builds" case, but the arch-os naming doesn't help with *that* at all, the potential benefits I see are more far fetched. But, it's useful to shake things a bit, it doesn't *have* to be BUILDROOT just because we've had such a thing in the past. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1929457570 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)
@ffesti pushed 1 commit. 7bd59e2a6146da8765a091dad197a7bcd1df4013 Update docs/manual/conditionalbuilds.md -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2405/files/5eee9f7e9194288a7fde10f095861fa0364ebdad..7bd59e2a6146da8765a091dad197a7bcd1df4013 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)
@ffesti 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
Yeah, that looked funny but then I compared it to the ones above...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#discussion_r1479716658
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'll still want to see the "real-world" test cases added to this. The gotchas and bugs are always in the part that you didn't think needs testing :laughing: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929442665 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)
@pmatilai 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
%bcond_, not %bcon_. Multiple cases of that in the above section.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#pullrequestreview-1865038372
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] Enhance the recoverability and location of database exceptions (Issue #2828)
Do you have anything in place to mitigate these issues. Like rebuilding the rpmdb on boot or in some cron job. I have seen people actually messing up their database this way by methods that where still helpful in the bdb days. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1929408350 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 "local_generator" (PR #2734)
One more thing wrt the macro name: I wonder if this is a case where it should *not* have those leading underscores. The generator itself is full of those, but the newly added macro here is something directly intended for packager use. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1929405020 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)
Yes. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929403698 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 "local_generator" (PR #2734)
@pmatilai commented on this pull request.
> @@ -995,6 +995,25 @@ runroot rpm -qp --requires
> /build/RPMS/noarch/shebang-0.1-1.noarch.rpm|grep -v ^
[])
RPMTEST_CLEANUP
+AT_SETUP([Local dependency generator])
+AT_KEYWORDS([build])
+RPMTEST_CHECK([
+RPMDB_INIT
+
+runroot rpmbuild -bb --quiet \
+ --define '__local_file_attrs my_test_attr' \
+ --define '__my_test_attr_provides() foo(%{basename:%{1}})' \
+ --define '__my_test_attr_path .*' \
This covers on of the use-cases, but the excess free() in the code kinda proves
that we need a test for the other scenario too where there's a pre-existing
attr by the same name.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1865004852
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] Allow to specify a default for bcond features in a macro file (PR #2405)
OK, renamed to `bcond_override_default`. This is hopefully used sparingly enough that the additional typing won't kill anyone. I added some documentation to the Conditional Build page. This should answer the questions above. But someone please prove read them. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929389639 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)
@ffesti pushed 1 commit. dbb795984108e325841e8ca5c5c053c3dcd67731 Allow to specify a default for bcond features in a macro file -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2405/files/20f501d1ad08a4182326a9ef682b525c709b5a03..dbb795984108e325841e8ca5c5c053c3dcd67731 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 "local_generator" (PR #2734)
@pmatilai commented on this pull request.
> - bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+ nfiles = argvCount(files);
+}
+char * local_attr_names = rpmExpand("%{?__local_file_attrs}", NULL);
+ARGV_t local_attrs = argvSplitString(local_attr_names, ":",
ARGV_SKIPEMPTY);
+nlocals = argvCount(local_attrs);
+fc->atypes = xcalloc(nfiles + nlocals + 1, sizeof(*fc->atypes));
+
+for (int i = 0; i < nfiles; i++) {
+ char *bn = basename(files[i]);
+ bn[strlen(bn)-strlen(".attr")] = '\0';
+ // skip file attrs found in __local_file_attrs for now
+ for (j=0; (j < nlocals) && strcmp(bn, local_attrs[j]); j++);
+ if (j < nlocals) {
+ free(bn);
Might be more readable to just toss all basenames into a new argv with
argvAddUniq() , which frees us from having to care about these details here.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#discussion_r1479661477
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 there a way to merge several RPMs (Discussion #2887)
> I guess what you mean by "merging" is something entirely different than me & > ffesti think of. In my naive view, I see binary RPM as nothing more then (fancy) tarballs. And combining two tarballs is legitimate operation AFAIK, given there is `tar --concatenate` option. > Binary rpm's are immutable end products of a spec which directs rpmbuild to > produce said rpms. Somehow undoing a separation set by the packager is just > not a meaningful operation at all. The only meaningful merge in rpm land is > something a packager does, at a spec/srpm level. I see it differently. If you abstract away, then several merged RPMs gives you e.g. container image (Yes, I have deliberately removed a lot of complexities). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8381793 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 "local_generator" (PR #2734)
@pmatilai commented on this pull request.
> - fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
- bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+ nfiles = argvCount(files);
+}
+char * local_attr_names = rpmExpand("%{?__local_file_attrs}", NULL);
+ARGV_t local_attrs = argvSplitString(local_attr_names, ":",
ARGV_SKIPEMPTY);
+nlocals = argvCount(local_attrs);
+fc->atypes = xcalloc(nfiles + nlocals + 1, sizeof(*fc->atypes));
+
+for (int i = 0; i < nfiles; i++) {
+ char *bn = basename(files[i]);
+ bn[strlen(bn)-strlen(".attr")] = '\0';
+ // skip file attrs found in __local_file_attrs for now
/* */ comments, thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1864948185
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 "local_generator" (PR #2734)
@pmatilai commented on this pull request.
> - bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+ nfiles = argvCount(files);
+}
+char * local_attr_names = rpmExpand("%{?__local_file_attrs}", NULL);
+ARGV_t local_attrs = argvSplitString(local_attr_names, ":",
ARGV_SKIPEMPTY);
+nlocals = argvCount(local_attrs);
+fc->atypes = xcalloc(nfiles + nlocals + 1, sizeof(*fc->atypes));
+
+for (int i = 0; i < nfiles; i++) {
+ char *bn = basename(files[i]);
+ bn[strlen(bn)-strlen(".attr")] = '\0';
+ // skip file attrs found in __local_file_attrs for now
+ for (j=0; (j < nlocals) && strcmp(bn, local_attrs[j]); j++);
+ if (j < nlocals) {
+ free(bn);
This is not right, basename() doesn't allocate, so this would free some random
pointer inside the one that is.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1864947811
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 an rpm-controlled per-build directory (PR #2885)
> These details are nowhere near fully thought through, and are certainly > debatable and open/subject to change. In my initial patch buildroot was > always BUILDROOT, but then experimenting with the vpath build stuff and your > own mention about potentially needing multiple build directories made me > think perhaps it should match the build directory name, and those are > commonly named by the target tuple. While I think multiple directories for vpath builds are useful, if `BUILDROOT` is still the image of what will be installed on the resulting system, then my current thinking is that there should be only one destination, where everything should be parallel installable if possible. But maybe you had the `curl` example with `RemovePathPostfixes` on your mind which could be legitimate reason. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1929343652 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 the recoverability and location of database exceptions (Issue #2828)
Backing up the database is not a perfect solution, but I've been plagued by corrupted databases that I can't locate for a long time, and the only solution I can think of is to back up the database. It would also be nice if there was some other way to deal with possible database issues or something to reduce the probability of problems. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1929339048 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 the recoverability and location of database exceptions (Issue #2828)
I'm using ndb database, I often encounter the following problems: 1. The problem of verification failure; 2. A rpm package cannot be queried by running the "rpm -qa" command, but can be queried by running the "rpm -q" command. Sometimes, the "rpm --rebuilddb" command can be used to rectify the fault. Sometimes, the "rpm --rebuilddb" command cannot be used. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1929324277 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 the recoverability and location of database exceptions (Issue #2828)
So is there an actual breakage you are seeing regularly? What database back end are you using? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1929225609 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 "local_generator" (PR #2734)
Ok, renamed back to `__local_file_attrs`. I squashed the patches and improved the docs a little bit. From my POV this is now complete. Can someone please prove read the docs? Thanks! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1929219489 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 "local_generator" (PR #2734)
@ffesti pushed 1 commit. 5ff3074187b888f9ff62416d9495fe36f7890468 Add %__local_file_attrs macro -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734/files/57334a2b0b0ad7d84e8e398bf6c6e6a8b53d2481..5ff3074187b888f9ff62416d9495fe36f7890468 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 4.19.1.1 bugfix update (PR #2888)
> > There are a few memleak fixes > > Oh, you mean (some commits from) #2879. Indeed, I somehow ignored this whole > PR due to it starting with "Add support for ..." I'll look at those patches > and see if cherry picking at least some of them would make sense, thanks. Yup, those. OTOH you could just as well pick the entire PR because the "add support" is only a developer/CI feature - one could argue memory leaks + the like are *more* important for stable releases than development ones. > > * maybe the unsigned buildtime thing that might be worth considering too. > > If you mean commit > [97aa64d](https://github.com/rpm-software-management/rpm/commit/97aa64d8281974fb369c66d5aef8650515b89c52), > that one is included in this PR. Or was there some other patch, too? Oh, ack, just missed that (was looking at the highlights more than actual commits it seems :sweat_smile: ( > > > Although, there's always the next release, so up to you. > > Agreed in general. These micro-micro releases are supposed to be rather small > so that we can produce them more often. :+1: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2888#issuecomment-1929050465 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 an rpm-controlled per-build directory (PR #2885)
> @kloczek , this is not about SPECPARTS although if you _look_ at the PR, > that's one of the issues that gets solved by this. See #2532 for the > background. On first look it looks like it is `setuptools` issue. .. like in other python modules cases (which I've mention here). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1929048282 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 an rpm-controlled per-build directory (PR #2885)
@kloczek , this is not about SPECPARTS although if you *look* at the PR, that's one of the issues that gets solved by this. See #2532 for the background. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1929038038 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 there a way to merge several RPMs (Discussion #2887)
I guess what you mean by "merging" is something entirely different than me & ffesti think of. Binary rpm's are immutable end products of a spec which directs rpmbuild to produce said rpms. Somehow undoing a separation set by the packager is just not a meaningful operation at all. The only meaningful merge in rpm land is something a packager does, at a spec/srpm level. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2887#discussioncomment-8379658 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 4.19.1.1 bugfix update (PR #2888)
> 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: > > `PKG_CONFIG_PATH=/usr/local/opt/libarchive/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig` > > So this looks great to me Sounds good, thanks for checking! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2888#issuecomment-1929009751 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 4.19.1.1 bugfix update (PR #2888)
> There are a few memleak fixes Oh, you mean (some commits from) #2879. Indeed, I somehow ignored this whole PR due to it starting with "Add support for ..." :smile: I'll look at those patches and see if cherry picking at least some of them would make sense, thanks. > + maybe the unsigned buildtime thing that might be worth considering too. If you mean commit 97aa64d8281974fb369c66d5aef8650515b89c52, that one is included in this PR. Or was there some other patch, too? > Although, there's always the next release, so up to you. Agreed in general. These micro-micro releases are supposed to be rather small so that we can produce them more often. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2888#issuecomment-1929009409 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] Proof-of-concept native support for vpath-style builds (PR #2886)
> 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).
The way builds are tied to %setup, I think there needs to be a way to achieve
this via %setup. It shouldn't be *tied* to %setup though. Having slept over it,
the approach in this draft doesn't cut it though. We want something that is an
opt-in for existing specs, yet something that can be made a default in
buildsystem macros with an opt-out for the occasionally buggy package. The -s
flag does not work for that. And, -s points at the source directory when it's
the *build* directory you'd like to be able to name, so it's quite backwards.
> > A one gotcha here is that special %doc and %license has traditionally
> > worked for both built and pre-existing content.
>
> The files could be gathered in `%{sourcesubdir}` followed by
> `%{buildsubdir}`, why not. But how often is the documentation build? It never
> came to my mind that the documentation could be generated during build and I
> wouldn't mind if only the former was possible. Or actually if neither one
> worked and the documentation would need to be installed into
> `%{_buildrootdir}` manually.
Building docs isn't uncommon at all, but whether the result gets included via
special %doc (as opposed to installing) is another question. It's a case we've
had in rpm itself too.
>
> BTW this does not update the `make` macros, right? Which are likely more
> noisy then the `configure` itself. IOW on one `./configure` call, there are
> typically two make calls, such as `make` and `make install`
There's nothing to update wrt the make macros. configure generates the
makefiles into the build directory, and then you just run make as you always
did.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1929002514
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 4.19.1.1 bugfix update (PR #2888)
There are a few memleak fixes + maybe the unsigned buildtime thing that might be worth considering too. Although, there's always the next release, so up to you. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2888#issuecomment-1928985700 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 an rpm-controlled per-build directory (PR #2885)
> 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.
These details are nowhere near fully thought through, and are certainly
debatable and open/subject to change. In my initial patch buildroot was always
BUILDROOT, but then experimenting with the vpath build stuff and your own
mention about potentially needing multiple build directories made me think
perhaps it should match the build directory name, and those are commonly named
by the target tuple.
All that is of course irrelevant within a single rpmbuild run, but down that
road far in the horizon one could imagine unpacking the source once, and then
executing just the build steps from other hosts using a read-only shared mount
of the source. Or (cross-) building on the same host for multiple targets at
once. Of course in such a scenario, SPECPARTS would have to be similarly
per-arch-os too, it's a valid point.
Wild visions aside, think of the (buildroot) rename more like shaking a tree a
bit to see what falls out rather than something decided.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1928974339
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
