In fact, the most difficult thing is that the database is suddenly damaged,
generally don't know what caused the damage(may be a power outage or a kill
process, etc.), so it is difficult to locate and repair.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-
AFACIT, the sub-package may include `Source` directive. But is there a chance
to have also named prep/build/... sections?
BTW wonder what happens with the string appended behind e.g. `prep`. Can I
really put there any garbage I like, such as `%prep asl;dkfjsld;fkj`? But I
assume this is likely
On systems without Doxygen, html pages are not built, but the install fails
with:
Install the project...
-- Install configuration: ""
CMake Error at docs/cmake_install.cmake:51 (file):
file INSTALL cannot find "/html": No such file or directory.
Call Stac
BTW looking around, `%source_name` used e.g.
[here](https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros.fedora-misc-srpm)
might be interesting concept and that is what I was aiming at in the last
paragraph.
--
Reply to this email directly or view it on GitHub:
https://gi
It is pretty common to provide versioned RPMs. E.g. in Fedora, there are
[nodejs20](https://src.fedoraproject.org/rpms/nodejs20/blob/rawhide/f/nodejs20.spec),
[nodejs18](https://src.fedoraproject.org/rpms/nodejs18/blob/rawhide/f/nodejs18.spec),
[python3.x](https://src.fedoraproject.org/rpms/py
Closed #2824 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2824#event-11500335713
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
RPM 4.18 and earlier had its own, non-standard and somewhat inconsistent glob
semantics in the `%files` section. In 4.19 we changed/fixed that to use the
standard, shell-like semantics, as defined in `glob(7)`.
That means, among other things, that quotes now turn off the meaning of any
metachar
**Description**
The *attribute marker* in `--verify` mode is only one character long, however
file entries may in fact have multiple attributes. For example, the following
are all valid entries:
```spec
%config %doc /etc/docfile
%config %license /etc/license
%config %ghost /etc/ghost
```
In the
Split to refactor + thread-safe fix, and restored that rpmugFree() on librpm
exit that had gone missing at some point.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893715068
You are receiving this because you are sub
@pmatilai pushed 3 commits.
4945ad298058fd3c325c6b803ef6c3e2cb2d97aa Remember to free user/group cache on
librpm shutdown (again)
8656e2e0327a9af38ef180eb014bac9271b3f8df Centralize user/group lookup caching
into a single data structure
d23eb53abdde25ad2c45d20c32dde255fb36384d Make user/group
@ffesti converted this issue into discussion #2845.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/589#event-11498460864
You are receiving this because you are subscribed to this thread.
Message ID:
___
There is `rpmdb --verifydb`. With the new rpmdb backends (sqlite and ndb)
issues with the database should be incredibly rare compared to the old bdb
days. If you are still experience rpmdb issues you are likely doing something
wrong. May be disable measures that still are left over from the bdb
Oh, except that rpmugGname() and rpmugUname() additionally rely on central
storage of the returned values so simple mutex locking doesn't work for those.
So those would have to be changed to return malloced data for a simple fix (it
wont break any users because there aren't any, at the moment).
It wouldn't be hard to introduce per-thread locking instead. The bigger deal
here is the new central struct that makes it possible to do stuff, perhaps I
should actually split that into a separate commit and then consider the thread
safety separately. The reason its lumped into one is basically
Yup, but this patch doesn't change that, the "leak" is already there. This only
makes it per-thread.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893568039
You are receiving this because you are subscribed to this th
OK, "ending itself" is a bit over dramatic... rpmChrootSet instantly returns if
there is now chroot so rpmugFree() is never called at all.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893557584
You are receiving this
FWIW, I think it's most easily fixable by relying on gnulib implementation?
https://github.com/coreutils/gnulib/blob/master/lib/glob.c
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2844#issuecomment-1893554648
You are receiving this be
Yes, this here seems save. Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2839#issuecomment-1893553825
You are receiving this because you are subscribed to this thread.
Message ID: __
Merged #2839 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2839#event-11497627945
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Yup, we recently refactored quite a bit of code related to glob handling, and
mostly went with the GNU `glob(3)` implementation, meaning that at least
`GLOB_BRACE` is indeed used now. Previously, we had our own implementation of
brace expansion, IIRC.
I'll have a closer look but it's possible t
It does leak, should've mentioned that in the commit message. In the sense that
each thread calling it will leave one cache around and reachable. It's far from
ideal but it's basically an emergency bandaid.
What do you mean about ending itself?
--
Reply to this email directly or view it on Git
Note that there's no technical reason for *not* adding the second argument (the
number of triggering packages) to transaction scriplets here, too. It's the
same code path underneath.
Whether it's useful or not is another question but I'll probably lean towards
consistency here and include it.
For completeness, we're going to patch rpm to ignore the braces if GLOB_BRACE
is absent, and if failures occur on musl systems, then they would be separately
fixed - so far none have been found:
```
>From f78e05544fb5ae9ef688963f19666f1af34c3d5c Mon Sep 17 00:00:00 2001
From: Alexander Kanavin
D
I wonder if this leaks memory. We create a new struct for each thread. Yes,
this is freed in rpmChrootSet but that is relying a lot on the right call
order.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893419277
Yo
Added buildroot itself to the description, there's no reason whatsoever to
scatter the built content around multiple directories if we have that one
top-level directory to rule it all.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/20
Right, that one. An architecture change is a fairly special operation, I'm not
convinced it needs to "just work" with regular update, it just needs to be
doable. Eg, using --replacepkgs, which back then it wasn't. Also, an i686
package *can* be considered an update to an i586 package, but a i686
26 matches
Mail list logo
