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
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
--
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
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)
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.
@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 ",
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
│ └── [...]
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?
--
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
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
> 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
> 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:
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
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:
```
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
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:
@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 \
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
@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
@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
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
@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
@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
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:
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:
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
@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
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:
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
@ffesti pushed 1 commit.
dbb795984108e325841e8ca5c5c053c3dcd67731 Allow to specify a default for bcond
features in a macro file
--
View it on GitHub:
@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 =
> 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
@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);
+
@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 =
> 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
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
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
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
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:
@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
> > 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
> @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
@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
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
> 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:
>
>
> 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
> 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
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:
> 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
49 matches
Mail list logo
