This branch has been obsoleted by #17. Please close this and review that one.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/11#issuecomment-146226805___
Rpm-maint mailing list
Rpm-maint@lists.r
It's not clear that `features.h` is included when it is supposed to be, and in
fact it wasn't. This should correct that.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/28
-- Commit Summary --
* Ensure features.h is include
So, as it turns out, pretty much all libc implementations except for legacy
ones implement it as `fstat64()`, so we will use `fstat64()` unless otherwise
necessary.
Also, fix typo in checking for `_D_EXACT_NAMLEN` definition.
You can view, comment on, or merge this pull request online at:
htt
Closed #28.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/28#event-463602765___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
So, it seems that `%{python:}` works as expected. However, scriptlets using `-p
` complain of it being unrecognized. Switching it to `-p `
fixes that, but the scriptlets don't run, and instead fail with the following:
```
warning: %postun(hello-2.10-27.1.fc23.x86_64) scriptlet failed, exit statu
Per the recommendation of Nick Coghlan and Toshio Kuratomi, `pythonXegg(M)` is
being renamed to `pythonX.Ydist(M)`.
An option has also been added to add a `pythonXdist(M)` Provides for
distributions that may prefer to have it. The option is intended for use if
only one python stack per major ve
So, I gave it another go, and while the scriptlets seem to work now,
interesting issues can come up.
It causes segfaults in Yum and DNF, and I suspect anything that uses bindings
to talk to RPM.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rp
Closed #33.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/33#event-477067853___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Per the recommendation of Nick Coghlan and Toshio Kuratomi, `pythonXegg(M)` is
being renamed to `pythonX.Ydist(M)`.
An option has also been added to add a `pythonXdist(M)` Provides for
distributions that may prefer to have it. The option `--majorver-provides` is
intended for use if only one Pyt
It should be just `%if %{with static}`.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/39#issuecomment-168231274___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/li
@ascherer Wouldn't it make more sense to split out the python macros into
`macros.python`?
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/38#issuecomment-168558259___
Rpm-maint mailing list
Rpm
@soig Could you please check to see if these would apply to #35? I've done some
refactoring there and I'd be happy to take in any changes authored by you to my
pull request. I've also added compatibility for your `pythoneggs(X)(M)` format
in Mageia there. I will happily accept PRs and patches to
This PR contains both #35 and #46
After reviewing the changes from @soig in #46, I've merged it into a new pull
request, after doing some tweaking and git sorcery. This obsoletes #35 and #46.
From #35
Per the recommendation of Nick Coghlan and Toshio Kuratomi, `pythonXegg(M)` is
being
Major change: introduction of attr file to enable the dependency generator
by default.
This pull request contains @soig's attr file to enable the dependency generator
by default, adapted to also read python wheel data too.
Do we want to enable this dependency generator by default in RPM, o
Closed #35.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/35#event-517361915___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
This pull request has been superseded by #49.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/35#issuecomment-172375774___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mail
Closed #49.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/49#event-517363906___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
This PR contains both #35 and #46
After reviewing the changes from @soig in #46, I've merged it into a new pull
request, after doing some tweaking and git sorcery. This obsoletes #35 and #46.
This PR differs from #49 in that it doesn't include the attr file to enable the
dependency generato
@soig I've reviewed your patches and merged them into mine and created a new
PR. #50 has them combined.
The only patch not merged in is the patch for enabling the new dependency
generator by default. I believe merging in the changes would be good, but
having the dependency generator enabled by
> @@ -1120,6 +1122,23 @@ done \
> %{__patch} %{-p:-p%{-p*}} %{-q:-s}\
> %{__bzr} commit %{-q} -m %{-m*}
>
> +# Subversion
> +%__scm_setup_svn(q)\
> +%{__svnadmin} create .svnrepos\
> +%{__svn} mkdir %{-q} -m "Create directory structure."
> file://`pwd`/.svnrepos/trunk\
> +%{__svn} checkout %{-
@ascherer It doesn't look like -S is supported anymore in `%autosetup`. Does
`%autosetup -S git` or something like that still work correctly?
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/56#issuecomment-176122690___
> @@ -1120,6 +1122,23 @@ done \
> %{__patch} %{-p:-p%{-p*}} %{-q:-s}\
> %{__bzr} commit %{-q} -m %{-m*}
>
> +# Subversion
> +%__scm_setup_svn(q)\
> +%{__svnadmin} create .svnrepos\
> +%{__svn} mkdir %{-q} -m "Create directory structure."
> file://`pwd`/.svnrepos/trunk\
> +%{__svn} checkout %{-
@ascherer Eck, I didn't override the macro properly to test, that's why... It's
all good to me :+1:
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/56#issuecomment-176159440___
Rpm-maint mailin
> @@ -1120,6 +1122,23 @@ done \
> %{__patch} %{-p:-p%{-p*}} %{-q:-s}\
> %{__bzr} commit %{-q} -m %{-m*}
>
> +# Subversion
> +%__scm_setup_svn(q)\
> +%{__svnadmin} create .svnrepos\
> +%{__svn} mkdir %{-q} -m "Create directory structure."
> file://`pwd`/.svnrepos/trunk\
> +%{__svn} checkout %{-
> @@ -1120,6 +1122,23 @@ done \
> %{__patch} %{-p:-p%{-p*}} %{-q:-s}\
> %{__bzr} commit %{-q} -m %{-m*}
>
> +# Subversion
> +%__scm_setup_svn(q)\
> +%{__svnadmin} create .svnrepos\
> +%{__svn} mkdir %{-q} -m "Create directory structure."
> file://`pwd`/.svnrepos/trunk\
> +%{__svn} checkout %{-
@cgwalters I'm not sure if I would say the Groups were a failure, unless you're
willing to elaborate on why.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/48#issuecomment-176185394___
Rpm-main
It's totally fine to submit this as a full pull request. If necessary, the
maintainers of the project can cherry pick from a pull request. It makes life
easier, in my opinion, to have them all in one pull request, anyway.
---
Reply to this email directly or view it on GitHub:
https://github.com/
> @@ -560,6 +560,7 @@ dnl Checks for library functions.
> AC_CHECK_FUNCS(putenv)
> AC_CHECK_FUNCS(mempcpy)
> AC_CHECK_FUNCS(fdatasync)
> +AC_CHECK_DECLS(fdatasync, [], [], [#include ])
`fdatasync()` was just replaced with `fsync()` in
6151ac9a298a9fe560cf8f899dc0b0e67453446c.
---
Reply to thi
> @@ -230,9 +230,9 @@ rpmvar_DATA =
>
> install-exec-hook:
> @rm -f $(DESTDIR)$(bindir)/rpmquery
> - @LN_S@ ../../bin/rpm $(DESTDIR)$(bindir)/rpmquery
> + @LN_S@ rpm $(DESTDIR)$(bindir)/rpmquery
This is a problem here. I have no idea where "rpm" exists in this symlink
creation ca
> @@ -86,20 +90,7 @@ char * stpncpy(char * dest, const char * src, size_t n);
> #define xstrdup(_str) rstrdup((_str))
> #define _free(_ptr) rfree((_ptr))
>
> -/* Retrofit glibc __progname */
> -#if defined __GLIBC__ && __GLIBC__ >= 2
> -#if __GLIBC_MINOR__ >= 1
> -#define __progname _
> @@ -86,20 +90,7 @@ char * stpncpy(char * dest, const char * src, size_t n);
> #define xstrdup(_str) rstrdup((_str))
> #define _free(_ptr) rfree((_ptr))
>
> -/* Retrofit glibc __progname */
> -#if defined __GLIBC__ && __GLIBC__ >= 2
> -#if __GLIBC_MINOR__ >= 1
> -#define __progname _
> @@ -86,20 +90,7 @@ char * stpncpy(char * dest, const char * src, size_t n);
> #define xstrdup(_str) rstrdup((_str))
> #define _free(_ptr) rfree((_ptr))
>
> -/* Retrofit glibc __progname */
> -#if defined __GLIBC__ && __GLIBC__ >= 2
> -#if __GLIBC_MINOR__ >= 1
> -#define __progname _
> @@ -230,9 +230,9 @@ rpmvar_DATA =
>
> install-exec-hook:
> @rm -f $(DESTDIR)$(bindir)/rpmquery
> - @LN_S@ ../../bin/rpm $(DESTDIR)$(bindir)/rpmquery
> + @LN_S@ rpm $(DESTDIR)$(bindir)/rpmquery
I would suggest making a new pull request that adds a configure switch for
changing t
Looks good to me :+1:
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/58#issuecomment-184071948___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
NetBSD and OS X aren't the only BSD derivatives with support for
`setprogname()` and `getprogname()`, so this PR adds the definitions for the
rest of them.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/59
-- Commit Summary
@ffesti The actual problem is that `/bin/rpm` isn't valid when you install to
`/usr/local`, and the symlinks unconditionally assume rpm is being installed
systemwide.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/60#issuecomment-184723
@ffesti What I was suggesting is that perhaps the following might solve the
problem better:
```
@rm -f $(DESTDIR)$(rpmbindir)/rpmquery
@LN_S@ -f $(rpmbindir)/rpm $(DESTDIR)$(rpmbindir)/rpmquery
@rm -f $(DESTDIR)$(rpmbindir)/rpmverify
@LN_S@ -f $(rpmbindir)/rpm $(DESTDIR)$(rpmbindir)/rpmverify
```
@petere After testing the patch, it seems like it's fine to me. I'm okay with
it entering as-is. :+1:
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/60#issuecomment-186955079___
Rpm-maint mail
These days, normally RPM is built with NSS. However, it is desirable in some
environments to use BeeCrypt as an alternative to NSS.
In my case, I wanted to use BeeCrypt instead of NSS for RPM for OS X. In my
quest to compile RPM for OS X, I have found a few things that needed to be
fixed. The f
In the `%apply_patches` that inspired `%autopatch`, patch application respects
the fuzz settings that are used for `%patch`. `%autopatch` and `%autosetup`
weren't using this, which led to an inconsistent patch application behavior.
You can view, comment on, or merge this pull request online at:
If it's okay, could this also be applied to the rpm 4.13 branch? It's biting us
hard in Mageia, and it'd be nice if this patch was included in the released rpm
4.13.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/63#issuecomment-1959561
The reference in `rpm.pc.in` is invalid and never gets filled in. By changing
it to the correct reference for `configure.ac` substitution, it should work as
expected.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/64
-- Comm
This pull request adds support for x86_64 for Darwin (Mac OS X) and adjusts the
logic slightly so that in the event an architecture is not defined, it throws a
warning.
Depending on how the architecture is set up, RPM may or may not properly detect
it, which is why this is a warning instead of
@proyvind Could the changelog be merged into the spec in an SRPM build or
something? Otherwise, there would need to be a way to declare that a particular
source in the spec provides the changelog.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@proyvind This current approach means that you should probably have a
"ChangelogFile" or some similar property that can be used in the preamble to
override the default file name (but not the path).
---
You are receiving this because you commented.
Reply to this email directly or view it on GitHu
Looks good to me as well, just a matter of @ffesti or @lkardos doing the final
review to pull it in.
---
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/74#issuecomment-2314505
Looks good to me! 👍
@ffesti @lkardos: I think this is sufficiently trivial that it can go straight
in...
---
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/76#issuecomment-2
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/77#issuecomment-237423581___
Rpm-maint mailing list
Rpm-main
@ffesti With this patch, I can build RPM on OS X again, so I'm happy with 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/78#issuecomment-238846977__
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1368673
Reported-and-tested-by: Igor Gnatenko
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/80
-- Commit Summary --
* pythondistdeps.py: Ensure that dist data used ha
Looks excellent 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/82#issuecomment-241387139___
Rpm-maint mailing list
Rpm
👍
--
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/83#issuecomment-241410563___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
ht
Tomas Orsava from the Fedora Python SIG requested that the dependency generator
support only using `pythonXdist(M)` format for both Provides and Requires, so
now this capability
exists.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/r
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/85#issuecomment-244376171___
Rpm-maint mailing list
Rpm-maint
@ffesti @ignatenkobrain Anyone have a chance to re-review after the rebase?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/17#issuecomment-245400085
Looks good to me! 👍
@ffesti What do you think?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/17#issuecomment-245801457___
Rpm-maint mailing list
@legionus I'd prefer to see a more detailed description in the commit itself
for future reference.
Otherwise, looks good to me!
What do you think, @ffesti?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com
> @@ -45,6 +45,20 @@ int rpmvercmp(const char * a, const char * b)
> continue;
> }
>
> + /*
> + * Handle plus separator. Concept is same as tilde, but it one of
> + * strings ends, it's considered as lower version.
Shouldn't this read "it's considered as higher vers
Looks good to me! :+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/pull/88#issuecomment-246129793___
Rpm-maint mailing list
Rpm-m
Looks great to me! :+1:
@ffesti @ignatenkobrain: What do you think? Can it be merged 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/86#issuecomment-246134715
👍
--
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/89#issuecomment-246203644___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
ht
Looks good to me as well. :+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/pull/92#issuecomment-248166812___
Rpm-maint mailing li
Conan-Kudo approved this pull request.
Looks good to me as well. :+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/pull/92#pullrequestreview-662858
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/93#pullrequestreview-3137787_
This PR changes `rpm2archive` so that in the event `RPMERR_ITER_END` is
returned back from `process_package()`, it will consider it successful and
return `EXIT_SUCCESS`.
Thus, shell scripts will be able to use rpm2archive the same way as most tools.
You can view, comment on, or merge this pull r
@pavlinamv Would it be possible to support the date+time format where the year
comes before the time? It's rather strange to see the year mentioned after the
time.
For example, your example date would be structured as:
Mon Jan 6 2016 09:02:22 CEST
--
You are receiving this because you are sub
@pmatilai It would also be a pure extension of the existing changelog date
stamp, as it would purely append new data in the date stamp, rather than mix it
up a bit.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gi
As of 57f94a582602f0353cdb17a02dc12c4461d4f32d, it's now possible
to have proper changelogs with dates and times properly set.
Thus, it makes sense to render this information by default.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rp
@ignatenkobrain The time information has always been present, according to
@ffesti. It's always been set to noon UTC before now, though. I verified by
manually doing the `rpm -q rpm --qf` command on Mageia Cauldron now, and saw
that the time information does exist and renders correctly.
--
You
@ffesti I've added a new option `--changes` to do this instead of changing
`--changelog`.
--
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/95#issuecomment-255330990_
@Conan-Kudo pushed 1 commit.
d2ce9a6 Add man page information for '--changes'
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/95/files/e5c217523864f4acf304a7005390ece561ae9631..d2ce9a6a76778033d0deba475
@proyvind The most simple case would be for SUSE, who uses `%{name}.changes`
for their changelog file name, though it's not currently in the correct form
for RPM changelogs (that can easily change, though). But there may be other
reasons (such as reusing changelog file or using a generated `chlo
No one is quite sure why there's a redundant `-python` suffix, but the module
isn't named that, and typically we want the name in the metadata to be the same
as the name of the module.
This has no effect on Python code itself, as it doesn't change the name of the
installed module used in import
These provides are specifically for packages providing AppStream files, which
are either going to be `*.appdata.xml` or `*.metainfo.xml` files in
`/usr/share/appdata` or `/usr/share/metainfo`.
The upstream AppStream specification mandates *.metainfo.xml files installed
into `/usr/share/metainfo
@mlschroe That's not how @ximion explained it to me. He seemed to indicate that
AppStream covers both aspects, and supersedes the old AppData spec.
--
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-softw
Conan-Kudo commented on this pull request.
> +#
+# Transform appdata/metainfo xml file into RPM appstream(filename) provides
+#
+# Author: Michael Schroeder
+# Based on other provides scripts from RPM
+
+OLD_IFS="$IFS"
+while read instfile ; do
+ case "$instfile" in
+ *.appdata.xml)
Hmm, apparently there is a difference...
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
--
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/98#issuecomm
@ximion Would `as-metainfo` work better as a name than `appstream` or
`metainfo`? I want it to be clear what this actually is (a form of AppStream
data).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rp
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/99#pullrequestreview-8949308_
I think I want to just leave it as `appstream()`, as then we won't get bitten
again by changes in what actually bits of AppStream are called.
--
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-ma
@ximion I've elected to change everything to `metainfo()`, as it resembles what
we did before with calling them `appdata()`.
--
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
@mlschroe I may come back later to make the generator a little smarter, but I
wanted the name/path fixed first, as I rely on it for stuff myself.
--
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-softwar
For a number of years, various Linux distributions (notably Fedora and Mageia)
have been overriding this to set it to use gnupg2, with no ill effects. Now
that most distributions are switching to gnupg2 by default, we will, too.
You can view, comment on, or merge this pull request online at:
h
@soig Removed the reference to Mageia, 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/101#issuecomment-262324925___
Rpm-ma
Today, RPM implicitly ties the build and host+target together, meaning that
every build is assumed to be a native build. However, this means that a few
desirable use cases are difficult to do with RPM:
* **Making packages to target a foreign architecture**: This is the main
cross-compilation ca
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/109#pullrequestreview-12224386___
I'm a bit confused. What exactly are MetaTags supposed to do? You mention
comps, are these supposed to be more like [SUSE's
patterns](https://build.opensuse.org/package/view_file/system:install:head/patterns-openSUSE/patterns-openSUSE.spec?expand=1)?
I can't quite tell what this is supposed to d
@proyvind @soig @ignatenkobrain Maybe it'd be better if it was not on by
default?
--
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/109#issuecomment-266029530
For those looking from GitHub and the URL is being weirdly borked, here's the
bug: https://bugs.mageia.org/show_bug.cgi?id=9832
--
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/p
There are plenty of people who prefer to have backup files created when
applying patches, for one reason or another. In #109, @proyvind proposed it to
be enabled by default.
This pull request tweaks that PR so that it is *not* enabled by default, but
still available by adding `-B`. In addition,
@soig Well, if someone wants to put themselves through the agony of using
gendiff to manage patches instead of an SCM, let's give them the tools to make
it less agonizing. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai Actually, it looks like that was GitHub's fault. The name of the
branch looks like how GitHub names them by default.
--
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
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/112#pullrequestreview-14818649___
@pmatilai Well, can you merge it and then delete the branch?
--
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/111#issuecomment-270171743__
Conan-Kudo approved this pull request.
Looks fantastic 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/116#pullrequestreview-15439382__
The correct change is to get the file/libmagic project to ship a file for
pkg-config to use and stop relying on creaky manual 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/
I believe @sgallagher from the Fedora Modularity group also was interested in
this...
Snippet from `#rpm.org` conversation back in October requesting it:
```
[Monday, October 17, 2016] [12:54:05 PM EDT] ffesti: I know this is
going to be a controversial question, but how hard would it be to sw
@pmatilai so you'd want instead a `-S patchbackup` backend instead of using
`-B` at `%autosetup`/`%autopatch`?
--
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/110#issuecomm
@pmatilai I'm tempted to not modify the default backend because of reasons
mentioned by @soig and @ignatenkobrain in #109. But let me see what I can do
about introducing an alternative backend that creates patch backups.
--
You are receiving this because you are subscribed to this thread.
Reply
Why not just replace `%` with `#`? That's what I generally do...
--
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/121#issuecomment-272155908
1 - 100 of 1213 matches
Mail list logo
