The problem is that nothing like this exists in rpm internally. The spec is
such an organigally grown hodgepodge that its simply impossible to impose
structure on where it does not exist.
Having sub-package information in meaningfully accessible data structures
sounds like a job for spec-ng,
Closed #573.
--
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/573#event-3160188654___
Rpm-maint mailing list
Sorry for not being more helpful but we as rpm upstream does not really know
what is best for Python packaging. So any solution that works for the Python
packaging community is fine with us. Closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Closed #395.
--
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/395#event-3160176246___
Rpm-maint mailing list
Closed #232.
--
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/232#event-3160168125___
Rpm-maint mailing list
Making BDB more reliable would require using transactions there, but this would
be an incompatible change, which is the last thing we want to do at this point
when we're basically just about to deprecate BDB. Which means we cannot do
anything about this, on Berkeley DB backend, unfortunately.
We really don't want to get into the business of string formatting and text
layout. Closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #566.
--
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/566#event-3160165222___
Rpm-maint mailing list
Or drop the support for old style debuginfo packages...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The issue here is that we do not actually want a weak dependency. The build
should not depend on some package availability in the direct sense. We probably
want to bind the dependency to something more robust.
--
You are receiving this because you are subscribed to this thread.
Reply to this
There's a use-case here alright, but I've a feeling the solution is something
quite different.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #581.
--
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/581#event-3159838486___
Rpm-maint mailing list
Looks like successor the the PR above got merged into redhat-rpm-config.
Closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Well, this may be technically a regression. But these packages can no longer be
created for quite some time. So we are not adding support for them back now.
Sorry.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #418.
--
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/418#event-3159785228___
Rpm-maint mailing list
But, yeah, maybe you guys have some other/better solution in mind. Idk.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Cool, ok, I admit I am not sure how big deal is the macOS compatibility. I
think if somebody complains that the feature doesn't work there, it would be a
reason to instead use some c library for the checksum validation. Maybe that
could be done immediately? I would still consider relying on
> Alright but I think we are maybe tracking different goals then :). I thought
> the issue was about making `%_disable_source_fetch 0` reliable. It's what the
> original post suggested to me.
It is about that. We don't want to operate on sources unless they've been
validated to be good. That
> > We could use a bit of bash code `%([ "$(sha256sum
> > | cut -d " " -f 1)" = ])` to do the verification per downloaded
> > source
>
> Yep, something like this is where I was heading to.
>
> > but i think `` might be slightly tricky unless rpm
> > exposes enviroment variable like
> We could use a bit of bash code `%([ "$(sha256sum |
> cut -d " " -f 1)" = ])` to do the verification per downloaded
> source
Yep, something like this is where I was heading to.
> but i think `` might be slightly tricky unless rpm
> exposes enviroment variable like 'SOURCES'
RPM exposes
On macOS, there is not a consistent interface for doing checksums via CLI. I'm
unsure if AIX and other platforms would also have similar problems.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1135 into master.
--
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/1135#event-3159498632___
Rpm-maint mailing list
Hmm, on Fedora:
```
$ dnf repoquery --requires rpm
Last metadata expiration check: 0:00:08 ago on Tue 24 Mar 2020 01:34:47 PM CET.
/usr/bin/bash
/usr/bin/db_stat
/usr/bin/sh
coreutils
curl
libarchive.so.13()(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libpopt.so.0()(64bit)
libpopt.so.0(LIBPOPT_0)(64bit)
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1135
-- Commit Summary --
* Move CI copy to later for more caching opportunities
* Add a ci make target for easy local running
-- File Changes --
M Makefile.am (5)
RPM does not *specifically* require GNU coreutils. And `sha256sum` and friends
are _not_ specifically available on all platforms RPM is used on.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> @voxik That is for verifying GPG signatures if they exist, and yes, it
> requires `gnupg2` as a build dependency in that scenario.
But if that was macro included in RPM, RPM would probably grow the dependency,
so it would not need BR. So I still think this could be way forward.
--
You are
It make sense. Here are some information to help you to make your choice.
Using Fedora instance only requires user to have a FAS account. No complex
workflows or approval of any kind.
Benefits I see is consistency with ecosystem (mostly RPM). And have a
structured community to interact with.
Being somewhat slower doesn't make it wrong. I'd rather leave it alone unless
the performance actually turns out to be a problem.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Trying to behave a civilized upstream for a change, and deprecate features
before removing? :grin:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@voxik That is for verifying GPG signatures if they exist, and yes, it requires
`gnupg2` as a build dependency in that scenario.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai Why didn't we just remove beecrypt? It's not like bdb where it has
drastic consequences for users whether it's available or not, and with having
libgcrypt, we don't need it anymore.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
This pull request **fixes 1 alert** when merging
a2576ab6fe8676cd9b15a3836590069b21d80713 into
4a9440006398646583f0d9ae1837dad2875013aa - [view on
LGTM.com](https://lgtm.com/projects/g/rpm-software-management/rpm/rev/pr-ddb4e54a84b9df329c644492b1256d7b6550da5f)
**fixed alerts:**
* 1 for FIXME
@pmatilai You'll then need to sign up for something with weblate.org.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I learned a bit more about sqlite in another project. Turns out that using a
custom match function is much slower than the LIKE version, because of sqlite's
LIKE optimization: https://www.sqlite.org/optoverview.html#the_like_optimization
So I think we should go back to use LIKE and escape the %
Reopened #1018.
--
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/1018#event-3159073617___
Rpm-maint mailing list
Thank you for the explanation.
> 0%{__isa_bits} == 64 should be the proper syntax.
BTW, I used originally "%if %{__isa_bits} == 64" as I found it in the official
documentation [here](https://rpm.org/user_doc/arch_dependencies.html). Please
consider to correct it, if without `0` it is somehow
@ffesti pushed 2 commits.
f5464cd88bbd6ce6315d4081953382fa6dc3c84b CI Dockerfile: Move copy command to a
later time
a2576ab6fe8676cd9b15a3836590069b21d80713 CI: enbale Python bindings
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
A linux specific way would be to offer some functions around inotify().
We can also try something more generic: We could create a named pipe in
/var/lib/rpm. At the start of the transaction we open the pipe O_WRONLY, at the
end we simply close the fd.
Some other process that wants to be
Closed #1133.
--
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/1133#event-3158875309___
Rpm-maint mailing list
You can't use ISA macros in a noarch package.
That it only fails in koji could be considered a bug in how rpm loads the
platform macros unless specifically using --target (which is what koji does),
but that's beyond the scope here.
--
You are receiving this because you are subscribed to this
Both versions:
- [%if %{__isa_bits} ==
64](https://src.fedoraproject.org/rpms/fixedptc/c/d9cb4b48e03e49b8865b20dacbfb81ef3192896a?branch=a420237f72f3d48a762fa6e967d3c38a443d59b0)
- works on rawhide on local mock and
> I actually wonder, why the check is done in `%prep`.
This might be due to `BR: gnupg2`, have not investigated this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thinking further about this, do we actually need something really fancy as
special tag?
For example, it is quite easy to check if the checksums in the dist-git sources
file are correct during `rpmbuild -bs`. It is enough to put `%(sha512sum -c
sources)` somewhere into specfile preamble. If the
This pull request **fixes 1 alert** when merging
48ee0c3ad781e2686cbc3cca5341443322cb3e5f into
4a9440006398646583f0d9ae1837dad2875013aa - [view on
LGTM.com](https://lgtm.com/projects/g/rpm-software-management/rpm/rev/pr-f6f7bf051c077acd3fc3b1f8981a30c22997b4fe)
**fixed alerts:**
* 1 for FIXME
Ok, thought so - as a principle, rpm cannot use distro-specific instances to
maintain an air of an independent upstream.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ffesti pushed 1 commit.
48ee0c3ad781e2686cbc3cca5341443322cb3e5f Add python2-devel to CI root
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Merged #1134 into master.
--
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/1134#event-3158426601___
Rpm-maint mailing list
Argh. When a thing starts going wrong...
Anyway, thanks for the patch.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai https://translate.fedoraproject.org/projects/dnf/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Shouldve been in commit 7de982ac0957c42f228b43685d9f486e55eac331
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1134
-- Commit Summary --
* Nuke leftover LMDB references in Makefile.am and Dockerfile
-- File Changes --
Hold your horses - what exactly is dnf using? Weblate okay, but which instance?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
No, the change is exactly as intended. When in doubt, I suggest to check what
it *actually* does.
The libtool version info is not equal to what ends up in the soname.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
52 matches
Mail list logo
