I agree --import needs some sort of "update" operation.
But any solution that may be developed in the future is not going to help the
*now* of Chrome users as there's no way to get it deployed to all the
(enterprise) distros out there. Google needs to use keys that are compatible
with how
(this is a "handsfree" item as using that info frees packagers from having to
manually add dependencies for these)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2148#issuecomment-1718804671
You are receiving this because you are
This is a dupe of #336, closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2334#issuecomment-1718800137
You are receiving this because you are subscribed to this thread.
Message ID: ___
Closed #2334 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2334#event-10367388450
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Right, this closely relates to #2078 as well.
Libarchive is currently an optional dependency, but a hard dep wouldn't be the
end of the world.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1718781153
You are
(this is "handsfree" item because the aforementioned, ah, specialty prevents
all sorts of interesting developements)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2205#issuecomment-1718802277
You are receiving this because you are
Hey, it's been quiet on this front for quite a while. Is this a case of "too
busy with other things", or is there something more to it? Just asking in case
somebody else wants to pickup this work.
--
Reply to this email directly or view it on GitHub:
Fedora has [perl-generator](https://src.fedoraproject.org/rpms/perl-generators)
package since 2014.
It contains perl.req, perl.prov and fileattrs based on rpm-4.11.2.
Over the years, there have been some updates in dependency detection and bug
fixes issues reported in Fedora.
We also added
Heh, yeah sometimes the most obvious answer is just too obvious :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2657#issuecomment-1717115125
You are receiving this because you are subscribed to this thread.
Message ID:
> Hmm, wouldn't `COMMAND sh -c ". /etc/os-release; echo ${var}"` achieve the
> same thing, by letting the shell do the work instead?
Yep, that's the "canonical" way to use `/etc/os-release`. For some reason, I
didn't realize this when adding this cmake helper.
@dmikushin, feel free to update
Indeed. It makes one wonder why the file is formatted in a shell-like fashion
:smile: Also, I just noticed this is also what `man os-release` illustrates in
the `Example 3. Reading os-release in sh(1)` section.
--
Reply to this email directly or view it on GitHub:
Oh, this "wonderful" quirk of C99. I wonder why newer gcc doesn't complain
because I don't think it's legit in C11 either.
Fixed a little differently in 34d983fa2a9b9276fc540b6bd554605b2c72689a because
I hate the way those locally added blocks mess up the git history (or blame
rather), and for
Closed #2656.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2656#event-10356304616
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Hmm, wouldn't `COMMAND sh -c ". /etc/os-release; echo ${var}"` achieve the same
thing, by letting the shell do the work instead?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2657#issuecomment-1717082230
You are receiving this because
An old version not supporting something is not a valid reason to drop an
important flag, see 1b70fd23bc45d2ec8a97c09b06fc3d7011b34cfc. In general
RHEL-latest is the ballpark line where where things need to compile + work,
bubblewrap 0.4.0 is RHEL-8 era and so doesn't count, but even 9 has only
@dmnks requested changes on this pull request.
Mentioned above.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2657#pullrequestreview-1623916057
You are receiving this because you are subscribed to this thread.
Message ID:
Or rather, just document the version requirement. Writing tests for every dark
corner gets old real fast.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2658#issuecomment-1717230615
You are receiving this because you are subscribed to
As our plugins become public there needs to be some ways to check they're
compiled for a compatible version of rpm. Many will get that enforcement
through rpm soname but technically there's no requirement for a plugin to link
to librpm* and .. better safe than sorry with mysterious bugreports
Indeed, `--clearenv` is there to ensure we run the tests in a clean
environment. It also means we don't have selectively unset the various env vars
in the container that could interfere with the test. The current tests *might*
still work even without `--clearenv` but we don't want to change
Closed #2658.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2658#event-10356637571
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Weve procrastinated on making this API public for about ten years now, and
in the meanwhile there has been exactly one disruptive change to the API. As
in, it mightve just as well been public all along.
There will always be more things to improve wrt any API, but were not
going to hold this
> For the record, we're currently
> [working](https://github.com/rpm-software-management/rpm/issues/2643) on a
> unified backend that will get rid of distro-specific scripts and only use
> podman images. Bubblewrap may or may not be required on the development
> system, I'm still not entirely
Oh yup, we would have to check for that manually as there doesn't seem to be an
RPM-like construct for program versions in `find_program()`. In that case, yes,
we'll just document that in the README file as part of #2611.
--
Reply to this email directly or view it on GitHub:
Details in the commits, but executive summary is to force some structure to the
fast and loose way private includes are used. While at it, clean up the
top-level source directory to be free of source code, it doesnt really
belong there. Looks huge, but for all practical purposes this is just
Merged #2660 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2660#event-10357896313
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #1536 as completed via #2661.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1536#event-10358631174
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2661 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2661#event-10358630689
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #2663 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2663#event-10359617114
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Shouldve been in 6ec0e4069e61fca3a5391c65effe72b2c782730d but at that time
cmake in Fedora had a dependency on rpm making this hard or at least ugly. With
that dependency fixed and workarounds removed from the test-suite, we can now
run cmake in there.
You can view, comment on, or merge this
@pmatilai pushed 1 commit.
cfc79e1e7426e07aeef9e3d2b663878285ddf22b Add a testcase for librpm development
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2663/files/c90ce91e239a1bb41cc305fc452f3c56987015ae..cfc79e1e7426e07aeef9e3d2b663878285ddf22b
You are receiving
Note that because of compatibility concerns, we'd probably want this new
behavior in a new macro.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1718404293
You are receiving this because you are subscribed to this
Keep in mind, we need a way to run it directly on the host, because all this
fanciness you're talking about doesn't exist on non-Linux platforms. In
particular, I would like to be able to run the test suite for RPM on macOS
still.
--
Reply to this email directly or view it on GitHub:
I will also point out there are openSUSE containers that use DNF too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1718407495
You are receiving this because you are subscribed to this thread.
Message ID:
In a conversation in
[`#devel:fedoraproject.org`](https://matrix.to/#/#devel:fedoraproject.org) with
@penguinpee, I realized that there's a potential quality of life improvement we
could look into making around `%setup`: Making it so we don't ever need to use
`-n`.
It started with asking
34 matches
Mail list logo
