LGPLv2.1(+) or GPLv2(+) is fine with 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/471#issuecomment-485118161___
Rpm-main
- [x] @scop ok with relicensing under MIT
--
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/595#issuecomment-437430364___
Rpm-mai
> I don't think that passing -E is good
Could you elaborate on that a bit, especially when you think -s /is/
good? Without -s, code from user site packages is loaded, potentially
interfering with the commands. Without -E, PYTHONPATH from environment
can be used to do exactly the same.
(If python3
To limit environment and user home dir influence.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/341
-- Commit Summary --
* Invoke python-macro-helper with -Es python args
-- File Changes --
M macros.in (6)
M scri
@pmatilai @Conan-Kudo ping?
--
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/221#issuecomment-338811478___
Rpm-maint mailing list
scop commented on this pull request.
> @@ -0,0 +1,27 @@
+#!/usr/bin/python -tt
Shouldn't really matter all that much, because the script is invoked with an
explicit "outside" interpreter without the shebang affecting anything, but
meh... dropped.
--
You are receiving this because you are su
@scop pushed 1 commit.
9e192ce python-macro-helper: Drop -tt from shebang
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/221/files/f4ee9662cf5c0a04e1928487f1480eccc6d598b1..9e192cef134dd149e7813e7fc93b
Rebased. @pmatilai ping?
--
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/221#issuecomment-325380081___
Rpm-maint mailing list
Rpm
I don't see how this change would affect that use case at all. Before this
change, the macros were expanded using `%{__python}`, and they still are (the
shebang in the scriptlet is not used).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vi
Ping?
--
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/221#issuecomment-310887287___
Rpm-maint mailing list
Rpm-maint@lists.rpm.or
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/241
-- Commit Summary --
* Spelling fixes
-- File Changes --
M CHANGES (18)
M build/files.c (4)
M doc/hacking.doxy.in (2)
M doc/librpm.doxy.in (2)
M doc/
Combining done, script renamed to python-macro-helper. I think the installation
point in rpm's dir structure serves as a prefix/namespace 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-softwa
It'll take me about a week and a half until I'll get back to this. If anyone
wants to ahead with this in the meantime, please feel free.
--
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-managem
`python_sitedirs` is otherwise fine, but it will also in its current form be
used to retrieve the python version, which seems a bit odd to me. Also, perhaps
it will be extended to generate some new other macros in the future. I'm
currently thinking along the lines of `python-macrotool` or `pytho
Having the utilities to generate these variables shipped with rpm would mean
downstream consumers could use them to generate the macros they desire. For
example Fedora could reuse them to generate python2_* and python3_* etc. I
intend to submit a patch doing exactly that against redhat-config-rp
Oh well, anyway, since it was not my purpose to actually make the sys.stdout ->
print changes, they're back to sys.stdout.write in this latest revision.
--
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-
Oops, the print stuff is like I said in the macros shipped by Fedora's
python-rpm-macros, not here (here they were using sys.stdout.write). But the
rest of what I said still stands.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on G
`.py` suffixes removed.
I don't think there's anything fragile about this particular use of `print`,
nor does it require the `print_function` import. It is also nothing new, the
previous `%python_sitelib` and `%python_sitearch` definitions used it too.
--
You are receiving this because you are
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/221
-- Commit Summary --
* Use scripts instead of python -c to retrieve %python_* values
* Get %python_version from platform.python_version_tuple
-- File Changes --
M
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/112
-- Commit Summary --
* find-lang.sh: Add --with-kde KF5 support
-- File Changes --
M scripts/find-lang.sh (13)
-- Patch Links --
https://github.com/rpm-software-ma
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/73
-- Commit Summary --
* Remove some unnecessary assignments flagged by cppcheck
-- File Changes --
M build/parseSpec.c (2)
M lib/rpmgi.c (1)
M tools/elfdeps.c
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/71
-- Commit Summary --
* python: Fix signalsCaught() docstring
* python: Trivial code cleanups
* python: Remove unnecessary shebang
* python: Close file in _f2hdr also
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/70
-- Commit Summary --
* Spelling fixes
-- File Changes --
M doc/rpmspec.8 (2)
M lib/rpmfi.c (2)
M lib/rpmtriggers.c (2)
M misc/rpmxprogname.c (2)
M pyt
...except long lines warnings.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/31
-- Commit Summary --
* pythoneggs.py: flake8 fixes
-- File Changes --
M scripts/pythoneggs.py (40)
-- Patch Links --
https://github.co
diffutils is a rpm-build dependency anyway nowadays, e.g. find-debuginfo.sh
uses cmp too. See PR #16 for discussion.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/30
-- Commit Summary --
* brp-python-hardlink: Use cmp ins
On Thu, Sep 18, 2014 at 1:38 PM, Michael Schroeder wrote:
>
> Well, 0.95_01 is actually more correct than 0.9501. Perl's versions
> are actually more or less floating point numbers, thus 0.9501 is
> supposed to be less than 0.96.
>
> From rpm's side, '_' is exactly equivalent to '.', so 0.95_01 is
On Thu, Sep 18, 2014 at 9:38 AM, Jerome Quelin wrote:
> This patch only acknowledges this fact, and allows _ in versions.
This results in the underscores also ending up in the Provides. I
don't think that's a good thing as IIRC rpm's version comparison does
not treat it the same way as perl does.
---
python/rpm/__init__.py| 18 --
python/rpm/transaction.py | 15 ++-
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/python/rpm/__init__.py b/python/rpm/__init__.py
index 196be3c..3b750db 100644
--- a/python/rpm/__init__.py
+++ b/python/rpm/__init
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ec85ede..7351291 100644
--- a/configure.ac
+++ b/configure.ac
@@ -90,7 +90,7 @@ fi
dnl
dnl Find some common programs
dnl
-AC_PATH_PROG(__7ZIP, 7zip, /usr/bin/7za, $MYPATH)
+AC_
---
CHANGES| 20
INSTALL| 12 +-
autodeps/freebsdelf.req| 2 +-
autodeps/hpux.prov | 2 +-
autodeps/osf.req | 2 +-
lib/fsm.c | 4 ++--
lib/header.c
Hello,
I'm considering using lua in some scriptlets, and noticed that while
posix.symlink() currently exists in the posix extension included with
rpm, it no longer exists in the current upstream version, there's a 3rd
argument to posix.link() instead for that purpose:
https://github.com/rrthomas/l
On 03/03/2011 05:36 PM, seth vidal wrote:
rpm[$pid:[$processname|$depsolvername]] pkgname pkgstate/action
I wouldn't make it easy to add anything but $appname[$pid] to that part
of the log entry; I suspect it could cause problems with existing
software that parses the logs and expects to fin
On 03/03/2011 01:44 PM, Panu Matilainen wrote:
Some (stylistic) issues with the patch though:
A couple of other thoughts, perhaps for future development:
Add some way of specifying the syslog ident string instead of hardcoding
it. That way logging from for example those upper level depsolver
On Thursday 25 November 2010, FlorianFesti wrote:
> Hi!
>
> There have been various issues with packages that demand a special order
> of installation but do not want to Require the package to be installed
> first. So a tag that is like Requires: during ordering but ignored
> otherwise is needed.
Hello,
It seems that RPMTAG_TRIGGERUN (maybe others too?) is not available in
rpm.tagnames or rpm.RPMTAG_TRIGGERUN in Python. Is this on purpose?
I believe this causes yum to output messages like "Non-fatal
scriptlet failure in rpm package foo" (the "" part) for failing
triggerun scripts.
__
On Friday 09 April 2010, Michael Schroeder wrote:
> Maybe NOSOURCE/NOPATCH should not be internal
> at all, though. They are useful to check if a rpm is "src" or
> "nosrc", there is no other way to detect this.
I don't know if it's correct, but in rpmlint we decide that based on whether
the sourc
On Thursday 15 October 2009, David Malcolm wrote:
> +WITH_PYTHON_INCLUDE=`${PYTHON} -c 'from distutils.sysconfig import *;
import sys; sys.stdout.write("%s\n" % get_python_inc())'`
I think the last statement could be just "sys.stdout.write(get_python_inc())",
no need for the newline.
On Wednesday 09 September 2009, Florian Festi wrote:
> Having a look at the tar formats I do not belief that switching to tar
> is a real option. The format is just horrible (GNU tar needs over 200
> lines to read an integer out of a header field) and full of hacks to
> remain backward compatible
On Monday 31 August 2009, Karsten Wade wrote:
> I don't easily see where the source for the updated MaxRPM snapshot
> is; that would be helpful in gathering a list of all copyright
> holders.
It used to be in a Mercurial repository at http://hg.rpm.org/max-rpm but that
doesn't seem to exist any
On Friday 10 July 2009, Karsten Wade wrote:
> Essentially, I'd like to get your consensus that as Fedora Docs folks
> work on max-rpm, they can go ahead and relicense the content to CC BY
> SA 3.0. In fact, I would recommend that be the first and a single
> change made in the source repo by the d
On Thursday 16 April 2009, Panu Matilainen wrote:
> More detailed compatibility information about the new features is
> available in http://rpm.org/wiki/Releases/4.7.0#Compatibilitynotes
I would add a compatibility note about *.py in s?bin dirs no longer being
byte-compiled: if one used %exclude
Hello,
The attached patch improves Qt translation support in find-lang.sh, especially
the --all-name part of it. I suppose this could be implemented in a prettier
way by someone with better sed-fu than mine, but this works for me. One test
case is Qt 4 (/usr/share/qt4/translations in Fedora 9
On Wednesday 26 November 2008, Jan Engelhardt wrote:
> rpm's configure script cannot find nss/nspr even though these are
> installed. As it turns out, configure.ac does not use nss/nspr's
> pkg-config files
Unless I'm mistaken, upstream nss and nspr do not ship pkgconfig files,
they're distro ad
On Tuesday 02 September 2008, Richard W.M. Jones wrote:
> I don't know if this is the new version of RPM in Fedora Rawhide, or
> just coincidence, but recently I've noticed that RPM has become even
> more aggressive about stripping binaries.
Just out of interest, how? Is strip invoked bu rpmbuild
On Monday 07 July 2008, Stanislav Brabec wrote:
> Nesreen wrote:
> > 1- I wander that upon making a package using RPM software, can I
> > assign version/build numbers for each file included in my package ,
>
> No, you cannot. Version/release are assigned only for packages. But you
> can have one f
On Wednesday 19 March 2008, Tom Brown wrote:
> # rpm -ivh
> /usr/src/redhat/RPMS/noarch/xxx-sun-java-custom-1.6.0_04-1.noarch.rpm
> error: Failed dependencies:
> jdk = 1.6.0_04-fcs is needed by xxx-sun-java-custom-1.6.0_04-1.noarch
>
> # rpm -qa | grep jdk
> jdk-1.6.0_04-fcs
>
> and the spec
>
On Thursday 28 February 2008, Panu Matilainen wrote:
> To be exact: of course the very script of the installed package wont run
> ever again, but in nearly all cases an updated version of the package will
> have the same dependencies on it's pre/post, thus bringing back the
> dependencies you just
On Tuesday 26 February 2008, Panu Matilainen wrote:
> On Sat, 23 Feb 2008, Pixel wrote:
> > as for me i'm not convinced that "Requires(pre) not implying Requires"
> > is a feature. I would be in favor of "Requires(xxx) implies Requires".
>
> Agreed, permitting remove of (pre|post|...)-only depende
On Monday 24 December 2007, Lennert Buytenhek wrote:
> Hi all,
>
> I noticed this (rpm 4.4.2.2):
[...]
> Apart from the funny way of writing %{?buildroot}, trying to coax
> 'make install' into installing files into %{buildroot} by redefining
> prefix= is very much the wrong thing to do.
With recen
On Wednesday 19 December 2007, Jim Galarowicz wrote:
> On some systems this works and on others we get blanks ( for
> %{depend_prefix} ) where we expected to get the path contained in the
> OPENSS_PREFIX environment variable. Is this a valid approach? Does anyone
> have a better scheme for this?
On Tuesday 11 December 2007, Scott Bambrough wrote:
> Pixel wrote:
> > afaik rpm does not order package removal :-(
>
> Interesting. The section on context marked dependencies in the
> snapshot version of Maximum RPM suggests it should.
[...]
> Is their a disconnect between the documentation and
Hello,
Attached is a patch for find-lang.sh containing the following improvements:
- spelling fixes
- POSIX compliance fix for find(1) usage
- Qt translation support
- localized man page support
- match *.omf, not *omf
Split patches available at http://scop.fedorapeople.org/patches/rpm/ if you
On Thursday 30 August 2007, seth vidal wrote:
> On Thu, 2007-08-30 at 18:09 +0300, Ville Skyttä wrote:
> > On Thursday 30 August 2007, seth vidal wrote:
> > > Hi,
> > > Would it be possible to add an option to the specfile parser or to
> > > rpmbuild that woul
On Thursday 30 August 2007, seth vidal wrote:
> Hi,
> Would it be possible to add an option to the specfile parser or to
> rpmbuild that would tell it to truncate the changelogs included in the
> package last N entries? It would default to including them all but give
> us the option of clipping of
On Monday 02 July 2007, Adam Jackson wrote:
> On Mon, 2007-07-02 at 21:50 +0300, Ville Skyttä wrote:
> > As for how many dependencies this would eliminate, running some quick
> > queries [0] against the Fedora primary sqlite metadata database told me
> > it'd be abou
Hello,
Is there a good reason why packages "export" dependencies on things that they
Provide/satisfy themselves? For example, if a package ships/provides
perl(Foo) and has some other things that also cause a dependency on
perl(Foo), wouldn't it be a good idea to just prune the dependency at bu
56 matches
Mail list logo