@Conan-Kudo pushed 1 commit.
b7c5b2a Add comment that lmdb is an option for %_db_backend
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/291/files/4039b5a77572408355aead32aed8cf24e95aa00f..b7c5b2a2e3d56
@Conan-Kudo pushed 1 commit.
3216dfc ci: Add lmdb-devel to CI Dockerfile
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/291/files/b7c5b2a2e3d56b8f59b5b81f369752686ce3825e..3216dfc0191c2a2e56ef0d47f0d7a
@Conan-Kudo pushed 1 commit.
6c40022 Enable looking for LMDB and building it by default
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/291/files/3216dfc0191c2a2e56ef0d47f0d7afd8d5c1e897..6c40022327e0ed
@Conan-Kudo pushed 1 commit.
c2cad9d Remove MDB_FIXEDMAP flag to prevent portability issues
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/291/files/2864bc4a3cb8905abbed1e833e50e03a6aded5d3..c2cad9da9e
@n3npq @hyc @ignatenkobrain This should be fully rebased now.
--
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/291#issuecomment-318926969_
Conan-Kudo approved this pull request.
--
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/225#pullrequestreview-53110650___
Rpm-
This PR adds support for zstd compressed payloads for RPMs. This addresses the
issues with duplicate m4 files with #283 and adds proper attribution.
Obsoletes #283
Closes #256
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/
@Conan-Kudo pushed 1 commit.
f86b7c2 ci: Add libzstd-devel to CI Dockerfile
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/295/files/5678c29a524d842403b068aa040a9f8ade7d4789..f86b7c211b5588b69620aac43d
Conan-Kudo commented on this pull request.
> @@ -348,6 +348,12 @@ static char *getIOFlags(Package pkg)
compr = "lzma";
(void) rpmlibNeedsFeature(pkg, "PayloadIsLzma", "4.4.6-1");
#endif
+#if HAVE_ZSTD_H
+ } else if (rstreq(s+1, "zstdio")) {
+ compr = "zst
@mlschroe Fixed.
--
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/291#issuecomment-319041353___
Rpm-maint mailing list
Rpm-maint@l
Conan-Kudo commented on this pull request.
> @@ -203,6 +204,20 @@ AC_CHECK_HEADERS([lzma.h],[
AC_SUBST(WITH_LZMA_LIB)
#=
+# Check for zstd library.
+
+dnl # Facebook Zstd
+RPM_CHECK_LIB(
`RPM_CHECK_LIB` makes it work when pkgconfig isn't available (macOS, etc.). It
also mak
@kanavin I think the only issue is the change to `%_libdir`. Is that really
necessary? It's set up that way so that it can be flexible. I'd rather see this
change reverted.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
ht
@kanavin What are you trying to accomplish?
--
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/263#issuecomment-319383816___
Rpm-mai
@kanavin The values in macros.in are overridden by the generated platform
macros: https://github.com/rpm-software-management/rpm/blob/master/platform.in
As far as I know, as long as you aren't purging the platforms, this doesn't
matter.
--
You are receiving this because you are subscribed to t
@pmatilai We could at least move things to `$(libexecdir)/rpm` and for Fedora
have a symlink for the old location to point to the new one. That'd keep things
consistent, right?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
Conan-Kudo requested changes on this pull request.
> @@ -8,7 +8,7 @@ Name: RPM
Description: RPM Package Manager
Version: @VERSION@
URL: http://rpm.org
-# Requires:
+Requires.private: @ZSTD_REQUIRES@
If this is linked in from librpmio, there's no reason to add
`Requires.private`, right? We
@kanavin @ignatenkobrain @pmatilai FHS 3.0 explicitly allows `/usr/libexec`
(aka `$libexecdir`), so using that path is not in violation of FHS.
--
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-
@kanavin I think if you prepare a patch to make this configurable (as @pmatilai
suggested) and fix the assumptions within RPM itself, that would go a long way.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
@n3npq I thought nodejs used [libuv](http://libuv.org/) nowadays? AFAIK, they
originally used [libeio](http://software.schmorp.de/pkg/libeio.html) +
[libev](http://software.schmorp.de/pkg/libev.html), but created libuv later on.
Do you have any particular insight into the differences (pluses/min
libeio is fine, I just wanted to know if you had considered the alternatives
and why this one was picked. It looks like libeio is still actively maintained,
which is good.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
htt
Thanks for the reasoning. 👍
--
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/258#issuecomment-320489857___
Rpm-maint mailing li
@n3npq I think he thought you had something ready to merge into RPM already. :)
--
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/258#issuecomment-320525269_
@kanavin Now that rpm 4.14 has been branched, could you rebase them for review
to merge 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/226#issuecomment-322755
@pmatilai Thank you for reviewing it!
--
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/291#issuecomment-323041501___
Rpm-maint mai
>From @n3npq:
> UUID's will be the starting point for a RPM+LMDB implementation used as
> header retrieval keys.
It didn't seem like you used this with the LMDB implementation
(ed9de1992f5e1c23e8d8dbd61325a1e0070f2c72), though you mention it as a starting
point. I'm guessing you're not currentl
I have to say that I agree with @n3npq on this. I don't even use `--predefine`
as it is, because it's a bit strange.
--
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/304#is
@mattdm wrote:
> In these days of version control, I think we've outlived the usefulness of
> having full changelogs in RPM files. Yet, it's still useful to have them in
> the specfile for workflows and build systems which haven't adapted to using
> version control changelogs.
This is absolutel
@mattdm I quoted the wrong thing, it was past midnight. I meant to quote the
bottom which said:
> The only downside I can think of is increased complexity in RPM when maybe we
> should just deprecate RPM changelogs entirely.
--
You are receiving this because you are subscribed to this thread
@mattdm The problem with that is that it's now impossible to retrieve the
changelog data in the metadata. It would make sense only if you were going to
impose a date cutoff, but that changelog information needs to be available
*somehow*.
There are at least a couple of bugs where people are expl
@n3npq So, the RPM-MD repodata published by Fedora *does* include the
information, it's just that DNF doesn't process it, even though it downloads it.
--
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-so
Conan-Kudo approved this pull request.
Looks good to me!
--
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/307#pullrequestreview-57572527___
@junaruga @proyvind It might need to be closed and reopened to trigger the CI
system to see it. I think @ignatenkobrain did that for a couple of other PRs...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com
Wrong. The big problem with `%_install_langs` is that you can't get the content
if the system changes. Instead, you have to reinstall the whole package.
By having subpackages, we can generate them with the correct rich dependencies
such that when a new locale is installed, all the software on th
@ignatenkobrain There's no obvious way to determine what should be the "base"
langpack bundled with the main software and the translations that should be
packaged separately.
A lot of software fall back to a base langpack when translations aren't
sufficient, and there's no easy way to tell what
Conan-Kudo requested changes on this pull request.
> @@ -0,0 +1,27 @@
+#!/usr/bin/python -tt
Please don't use `-tt`, as that switch is deprecated and removed in Python 3.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
ht
@proyvind We already load platform macros pretty early. They're in the search
order right after the generic macros, so why not leverage that for dynamically
loading platforms? Why do we need pre-macros when we can just define another
set of macros to load at the beginning of the search order (if
AFAIK, Docker is dumb and passes everything through to the host filesystem to
handle. So, yes...
--
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/commit/b7a869f0f322cbe428e78150f
Conan-Kudo approved this pull request.
--
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/324#pullrequestreview-61663848___
Rpm-
@cgwalters: This patch looks very specific to RPM-OSTree. Is there not a
better, more general way to do this?
--
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/320#issuecomme
> Why should rpm ever want to walk a remote URI?
There are at least a couple of occasions where it does. RPM is capable of
installing packages from remote locations. It'll fetch the RPM and go through
the correct process to install the package as described by the user. I use this
all the time f
@mhatle Would you consider proposing a patch to switch from `fakechroot` to
`pseudo`? It looks like we have `pseudo` in Fedora, and if RPM's testsuite
depends on it, I can introduce packages for Mageia and openSUSE so that the
test suite can be run there.
--
You are receiving this because you
@mhatle Aside from that, @n3npq mentioned this:
> Almost everything Just Works ... the few tests failing can likely be fixed
> rapidly.
If you could provide a PR with the change and fixed the failing tests, I think
it'd be quite appreciated.
--
You are receiving this because you are subscribe
@ldv-alt That's just rude. 👎
--
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/324#issuecomment-329169030___
Rpm-maint mailing lis
Regardless, having an `%elif` conditional statement makes sense. It's also a
bit weird that we haven't had it for so long...
--
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/issu
@pmatilai It doesn't sound like a bad idea to have `BuildRequires(stage)`,
though. That way global controls on stages would have the proper effects during
rpmbuild...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://
This PR supersedes #164 in an attempt to get some unit tests in for rich
dependencies.
Per the original PR, this is the coverage so far:
- [x] (X and Y)
- [x] (X or Y)
- [x] (X if Y)
- [x] (X if Y else Z)
- [x] (X and (Y or Z))
- [x] (X and (Y if Z))
- [ ] (X or (Y and Z))
- [x] (X or (Y if Z))
-
I think this is an excellent idea, but I'm not sure of the semantics of what
happens when something is redefined in another lua file.
For example, if `/usr/lib/rpm/lua.d/foo.lua` ships function `do_foo` and
`/usr/lib/rpm//lua.d/bar.lua` (in Fedora's case, the
`RPMCANONVENDOR` is `redhat`) ships
Today in RPM, we have dependency generators that allow us to automatically
match dependencies based on the content of the install tree. However, it's
still a lot of work for people to split out things into subpackages so that the
dependencies are matched up with the components they actually belo
@patrickc25000 What version of RPM are you encountering this? And what
distribution?
--
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/333#issuecomment-336671158___
Conan-Kudo requested changes on this pull request.
> @@ -13,6 +13,7 @@
# 2011-11-16 Per Øyvind Karlsen
# * add support for HTML files (from Mandriva)
+# * add support for multiple names
This distinctly didn't happen in 2011.
--
You are receiving this because you are subscribed to thi
When I attempt to build rpm 4.14 for macOS with the ndb rpmdb backend enabled,
it fails to compile due to the Linux-specific
[`mremap(2)`](http://man7.org/linux/man-pages/man2/mremap.2.html) syscall
missing.
```
depbase=`echo backend/ndb/rpmxdb.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
The typo in this check prevents rpm for correctly detecting compatibility with
OpenSSL 1.0.2.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/335
-- Commit Summary --
* configure: Fix typo for libcrypto usability check for
@pmatilai A couple of the tests are failing because they test the wrong way. I
haven't had a chance to fix them. I may not get to... @ignatenkobrain do you
think you can finish this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@pmatilai I can do that.
--
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/326#issuecomment-338644484___
Rpm-maint mailing list
Rpm
@pmatilai I dropped the broken tests.
--
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/326#issuecomment-338646419___
Rpm-maint mai
As someone who regularly hacks on dependency generators, this would absolutely
be valuable for me!
--
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/338#issuecomment-339019
Does anyone even know anyone in the glibc community to check and see if this is
even going to happen at all? Universal UTF-8 would be awesome, but right now
it's only available via patched glibc in Fedora, openSUSE, and Debian. It's not
available in Mageia or most other distributions who are pro
Is it really necessary for it to be dynamic?
--
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/commit/4220d488ff7d1096dd2cb89d4dca3627f0414c7e#commitcomment-25307819___
> Drop shebang from non-executable files.. Having shebangs in non-executable
> files doesn't make sense to me. If you think I'm wrong, I'm ready to listen!
The main reason you might see this is for example scripts in examples or things
like that. I'd rather not mangle anything that's installed t
@ignatenkobrain Yeah, I know, but we can easily filter on `%_docdir` as a
simple heuristic.
--
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/344#issuecomment-341274961__
@daurnimator Generally speaking, subtrees/submodules aren't really acceptable.
And we don't usually vendor in libraries.
That said, maybe @pmatilai might make an exception for the Lua stuff, I don't
know...
--
You are receiving this because you are subscribed to this thread.
Reply to this emai
@soig I personally don't think it's a good idea to eliminate file deps, as once
you use package names, they get more distro-specific. For example, `perl-base`
is a Mageia-only thing.
But that said, perhaps we want to support both (translating the dependency to
the correct file dep from the inte
@zoujiaqing If you want to avoid that issue, you can try using beecrypt crypto
backend instead of NSS.
--
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/340#issuecomment-34
@ignatenkobrain If we pull in a cleaned up version of #122, we will have a
consistent way to manage brp scripts via option 1.
--
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/pul
@pmatilai Wouldn't using `unmap()` + `mmap()` work as an alternative to bombing
out on `mremap()`?
--
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/334#issuecomment-341684
@ydario Sure, but then the question becomes, why `/dev/tty` is hardcoded then?
--
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/345#issuecomment-341733198
Conan-Kudo requested changes on this pull request.
> @@ -0,0 +1,3 @@
+%__os2_provides%{_rpmconfigdir}/os2deps.sh --provides
+%__os2_requires%{_rpmconfigdir}/os2deps.sh --requires
+%__os2_magic ^(32|64)-bit.*$
This magic is too broad. Is there a may to m
Conan-Kudo approved this pull request.
--
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/350#pullrequestreview-74173395___
Rpm-
Conan-Kudo commented on this pull request.
> @@ -0,0 +1,3 @@
+%__os2_provides%{_rpmconfigdir}/os2deps.sh --provides
+%__os2_requires%{_rpmconfigdir}/os2deps.sh --requires
+%__os2_magic ^(32|64)-bit.*$
Would this work? `^(32|64)-bit (OS\/2 executable|DLL
@ydario But they are ordinary DLLs, so they should be marked as such...
--
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/346#issuecomment-341920839___
Conan-Kudo commented on this pull request.
> @@ -0,0 +1,3 @@
+%__os2_provides%{_rpmconfigdir}/os2deps.sh --provides
+%__os2_requires%{_rpmconfigdir}/os2deps.sh --requires
+%__os2_magic ^(32|64)-bit.*$
I haven't tested it, so you should probably test. :)
So then probably there's a bug in the Python port in OS/2, since it should
reflect the proper extension...
--
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/346#issuecomment-
@daurnimator I don't know. I don't know enough about lua to make an educated
decision.
--
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/169#issuecomment-341964581___
The CI returned the following error:
```
Makefile.am:186: error: OS_OS2 does not appear in AM_CONDITIONAL
Makefile.am: installing './depcomp'
fileattrs/Makefile.am:13: error: OS_OS2 does not appear in AM_CONDITIONAL
scripts/Makefile.am:45: error: OS_OS2 does not appear in AM_CONDITIONAL
```
--
Y
The error in the CI is due to its dependency on #349.
--
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/351#issuecomment-343174862_
Erk, wrong PR for this.
--
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/350#issuecomment-343175043___
Rpm-maint mailing list
Rpm-
The error in the CI is due to its dependency on #349.
--
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/350#issuecomment-343174936_
The CI failures in this PR are unrelated to this change.
--
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/350#issuecomment-343175160__
This changes elfdeps to emit dependency strings that contain full
architecture names instead of just declaring whether something is
"64bit". This means that systems that allow more than two architectures
to be installed on the same computer will actually be able to resolve
library dependencies corr
@mlschroe I originally had it with `--no-multiarch` to disable for testing to
make it easy, and I thought it was okay to leave that way, but I switched it as
you asked.
As for why I didn't touch `addDep()`? It's easier for me to have a different
function when I want to generate both old-style a
@mlschroe Oh wait, I see what you're talking about. You mean use `addDep()` and
pass in the archmarker instead...
--
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/360#issuec
@mlschroe I removed the redundant `addArchedDep()` as it's identical and I can
just pass in the multiarch variant to be added.
--
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/pu
@mlschroe Done.
--
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/360#issuecomment-344594754___
Rpm-maint mailing list
Rpm-maint@li
Historically speaking, RPM's library dependencies have been only covered the
soname.
However, this has bitten us from time to time when the actual symbols have
changed. Some distributions solve this by actually generating dependencies
against both the version/soname and the library symbol name.
My understanding is that set-versions imposes the same requirement, only that
it's inscrutable to the user because it's hashed rather than in
user-comprehensible form.
You're correct that it may not necessarily require rich deps, though. I was
thinking of cases where a library may provide multi
@khardix This has not been true for many years.
As @n3npq noted, you can override this for your own purposes. What I suspect
you actually want is some trivial way to append to the load path specifically
for SCLs. That seems risky, and in general, I'm not sure it makes sense for
SCLs to ship the
@voxik It would be better if you didn't set it up to be unconditionally loaded.
RPM has had mechanisms to load macros for specific spec files for years. The
smart thing to do would be to have the sclification of a spec add a line at the
top to load the SCL macros files.
As many of the macros ov
@khardix It's not in the website, but it's in the documentation generated by
rpm itself:
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/macros#L91
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https
> 1. you have upstreams from hell like TeXLive that bundle many many unrelated
> parts of the same kind.
So you need some way to tell rpm "autocreate subpackages but split them around
those fileset lines"
Sure. And even in Solus' packaging mechanism, the user can override automatic
pattern matc
To @n3npq's point, that's pretty much what I did internally for some of our
workflows.
--
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/368#issuecomment-351088374_
@AdamWill
In almost every distribution (excluding Fedora) that was using Python bindings,
they were _not_ using the setuptools build. In fact, to date, I have not
encountered any significant applications that declared `rpm` or `rpm-python` as
a dependency in setuptools because most distributio
> I know of several codebases in this nexus, actually, because there are a few
> things people commonly want to do that there is no good Python library to use
> for. The infamous example is parsing NEVRAs; there was a function for doing
> this in hawkey, but then someone decided to kill hawkey.
@AdamWill The issue that I've been seeing is that people have been putting
`rpm` as the setuptools `install_requires`, which obviously never worked before.
In addition, many Linux distributions (RPM-based and not) didn't install the
Python bindings via `setup.py` and didn't provide the metadata
> But as you say, that never previously did work, so anyone who's previously
> tried and not just given up when 'rpm' didn't work must surely have landed on
> 'rpm-python', like I did.
Actually, what they did was just not specify it at all in setuptools. As I said
before, a lot of distributions
@n3npq There's nothing wrong from the RPM point of view. The problem is from
the python installed package index for tools like `pip` to process.
--
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
I think @SanketDG is referring to the fact the size can't be configured to show
human representation of storage usage. That is, equivalent to what [`ls
-hl`](https://www.mankier.com/1/ls#-h) does.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@stefanberger Is it possible to make this an optional thing to enable at
runtime? I don't see this being useful in general, and while it's "wanted", I
don't think a lot of people would want it normally.
--
You are receiving this because you are subscribed to this thread.
Reply to this email dir
> Me, I'd rather fix the name in Fedora 26 too and move on.
I'm okay with this, but I think it's fine to just Let The Past Die(TM) and with
RPM 4.14 onward, we'll have the right name.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
And until I changed it for openSUSE, it was never had the egg either. And
that's being introduced in openSUSE with v4.14. So, new name only.
--
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-man
The tests failed out on executing the one that isn't installed...
We'll also ensure it fails if neither GPG implementation is installed.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/378
-- Commit Summary --
* tests: Ensu
601 - 700 of 1212 matches
Mail list logo
