@mlschroe `%_build_arch` is the macro set in the platform macros for a target
platform to represent the RPM build architecture for a given platform. The
value is set to `RPMCANONARCH`, and probably is the right value to set this
to...
--
You are receiving this because you are subscribed to thi
@pavlinamv It is not true that the timezone short codes do not encode whether
daylight saving time/summer time is in effect.
For example, where I live, daylight saving time means Eastern Time is
represented with `EDT`, whereas standard time is represented as `EST`.
Europe has `CET` vs `CEST`, A
@mlschroe Most of our Rust packages do, yes.
```
ExclusiveArch: %{rust_arches}
BuildArch: noarch
```
--
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/791#issuecomment-5113
Hmm, we do have the problem, but it doesn’t seem to trip up our `ExclusiveArch`
usage, and I don’t know why…
```
[ngompa@localhost ~]$ mock -r fedora-30-ppc64le --init --forcearch=ppc64le
INFO: mock.py version 1.4.16 starting (python version = 3.7.3)...
Start: init plugins
INFO: selinux disabled
@mlschroe But `/usr/lib/rpm/platform/ppc64le-linux/macros` defines
`%_build_cpu` as `ppc64le`, so I *shouldn’t* see 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/issues/
@jasontibbitts In Mageia and OpenMandriva, rpmlint is executed as a post-build
check through rpmbuild itself, like so:
```rpmspec
%_build_pkgcheck_set /usr/bin/rpmlint -f %{_sourcedir}/%{name}.rpmlintrc
%_build_pkgcheck_srpm /usr/bin/rpmlint -f %{_sourcedir}/%{name}.rpmlintrc
%_nonzero_exit_pkgch
> On most architecture this works well, but there are cases with unexpected
> results. Our ppc64le rpm has _host_cpu and thus _build_cpu set to
> "powerpc64le".
How did this happen? On Fedora’s ppc64le `rpm` package, I’ve never observed
this issue…
--
You are receiving this because you are su
That sounds 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/issues/789#issuecomment-510851979___
Rpm-maint mailing list
Rp
It probably makes sense to make autotools patch this with `RPMCANONVENDOR` at
configure time...
--
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/779#issuecomment-509156031
@ignatenkobrain Changed.
--
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/785#issuecomment-508995482___
Rpm-maint mailing list
Rpm
@pmatilai, @ffesti: I really only have one question here... Do we want to
preserve the behavior we introduced in RPM 4.14? Or should I set the value of
the new macro to zero, and let people turn on the knobs as they want?
--
You are receiving this because you are subscribed to this thread.
Repl
@pmatilai, @ffesti, please cherry-pick this into the RPM 4.15 tree.
--
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/785#issuecomment-508981492___
Since b8a54d6a1e9bb6140b6b47e23dc707e4b967537e, when `SOURCE_DATE_EPOCH` is
set, `RPMTAG_BUILDTIME` winds up being set with that value. This is not always
desirable, particularly if you are using the build time for filters and
evaluation in certain types of package release pipelines.
This is an
@wladmis What is the value of considering the build-time? That would introduce
a nearly uncontrollable value that could trigger upgrades/replacements when it
is undesired.
At least in Fedora, openSUSE, and OpenMandriva, the package manager has the
option to "sync" the installed package set with
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/765#pullrequestreview-254346491___
Rpm
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/757#pullrequestreview-252203325___
Rpm
The code looks okay to me, and it seems to pass the tests, including the new
ones he wrote. 👍
--
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/754#issuecomment-503504629___
@wladmis So I've seen that this is more fleshed out in ALT Linux's rpm, do you
plan on finishing up this PR for consideration?
JFYI for everyone else, it looks like ALT has implemented `E:V-R:D` comparison
in their rpm 4.13.x tree, where the D is the DistTag. It looks like my
suggestion of labe
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/748#pullrequestreview-250266768___
Rpm
That's probably going to be a while. We'll need to figure out what the distros
are doing to popt, clean them up, and integrate them into the git repo before
we consider making a new release.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vie
This might wind up being somewhat painful, but it's a good idea to get spec
files to use a consistent text encoding.
--
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/716#iss
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/716#pullrequestreview-242549255___
Rpm
@kloczek OpenMandriva does not use them in any maintained packages.
I do know that PLD and ALT are active heavy users of these macros, though
neither of them are using this version of RPM yet.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or v
Conan-Kudo approved this pull request.
Looks good, just one issue...
> +# compiler flags.
+
+# C compiler flags. This is traditionally called CFLAGS in makefiles.
+# Historically also available as %%{optflags}, and %%build sets the
+# environment variable RPM_OPT_FLAGS to this value.
+%buil
Conan-Kudo commented on this pull request.
> +# compiler flags.
+
+# C compiler flags. This is traditionally called CFLAGS in makefiles.
+# Historically also available as %%{optflags}, and %%build sets the
+# environment variable RPM_OPT_FLAGS to this value.
+%build_cflags %{optflags}
+
+#
Conan-Kudo approved this pull request.
Eh. I guess...
--
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/691#pullrequestreview-233909488_
@pmatilai They are used in a few places and distros. But the main usage
probably stopped when `%GNUconfigure` went away. There's a `%autoreconfigure`
macro floating around somewhere that uses these as well...
--
You are receiving this because you are subscribed to this thread.
Reply to this ema
Conan-Kudo commented on this pull request.
>
find "$RPM_BUILD_ROOT" \! \( \
-name '*.pyo' -o -name '*.pyc' -o -name '*.elc' -o -name '.packlist' \
\) -type f -print0 | \
-LANG=C xargs -0r grep -F "$RPM_BUILD_ROOT" >$tmp
+LANG=C xargs -0r -P$NCPUS -n16 grep -F "$RPM_BUILD_ROO
> There's a gotcha in that logic BTW: more often than not, the %include'd file
> is actually a source of that package.
Yes, but in that case, it tries to pull it from `%_sourcedir` if I remember
correctly, and if it's not there, it bombs out on a parse failure.
--
You are receiving this becaus
@pmatilai I think my argument about this is that Sources and Patches aren't
needed for spec parsing, but stuff wrapped inside of an `%include` is, and in
those cases, it does pull the source file for that include. And I think that's
a fair compromise for spec parsing.
--
You are receiving this
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/686#pullrequestreview-231468759___
Rpm
@pmatilai I don't know if it's a good idea to make this a default behavior for
`rpmspec -P` or `rpmspec -q`... I think it'd be better if an option was
required to trigger this behavior, because the output is necessarily unreliable
and users should _choose_ to accept that unreliable output.
--
As one of the maintainers of
[`rpm-config-SUSE`](https://github.com/openSUSE/rpm-config-SUSE), I'm okay with
this idea and we could work out a plan for transitioning things to the
convention in `redhat-rpm-config`. I like them more than the ones in the SUSE
environment, as it's clearer what the
`ln -r` didn't exist before sometime in 2014, I think? AFAIR, EL6 doesn't
support it because of 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/issues/668#issuecomment-4
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/676#pullrequestreview-229497377___
Rpm
@nim-nim Subpackages *must* be evaluated because you can put BRs with
subpackages, and those are still collected and put into the main SRPM, among
other things.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github
Conan-Kudo commented on this pull request.
NAK. The rpmbuild tool serves as the validator of the spec file and attempts to
fail early if it looks like a broken package spec after evaluating the macros.
It's a very bad idea if SRPMs could be built with invalid spec files.
--
You are receiving
@nim-nim, @eclipseo: It would be deeply flawed if `rpmbuild(8)` allowed an
invalid spec file to be used for a package build. The `rpmbuild` tool serves as
the validator of the spec file and attempts to fail early if it looks like a
broken package spec after evaluating the macros.
--
You are re
You need an empty build section to get out defined properly, I think.
--
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/593#issuecomment-484917290_
Conan-Kudo requested changes on this pull request.
> @@ -1021,6 +1021,7 @@ package or when debugging this package.\
CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
+ LDFLAGS="${L
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/661#pullrequestreview-226230625___
Rpm
We don't even _have_ `BuildProvides` as it is...
--
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/657#issuecomment-480818360___
@ffesti Well, I mean why don't we just query for the static builddeps and
install them, then retrieve the `%generate_buildrequires` section and grab the
output and install that, then go forth and build normally?
--
You are receiving this because you are subscribed to this thread.
Reply to this
@ffesti Is there a reason we can't just do this by evaluating the spec file
instead of producing weird (no)src rpms?
--
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/593#iss
@pemensik You can use `%patch -P 123`
--
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/629#issuecomment-472658284___
Rpm-maint mai
@tarcieri If you actually do want to move them, let us know, and I'll poke
people with a pointy stick!
@pmatilai it actually wouldn't break any links because GitHub preserves them
for redirection.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@hroncok How would we translate `'nbconvert!=5.4'`?
Would we go with `Requires: (python3.7dist(nbconvert) < 5.4 with
python3.7dist(nbconvert) > 5.4)`?
Or would we enable Conflicts generation and translate this into the following?
```specfile
Requires: python3.7dist(nbconvert)
Conflicts: python3
@hroncok You mean `nbconvert`? I see `python3.7dist(nbformat)` in there...?
--
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/639#issuecomment-468941437_
@pavlinamv #625 was merged, so could you rebase this on top of current git
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/613#issuecomment-468939640___
🥇 🙇 💯
--
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/637#issuecomment-467655932___
Rpm-maint mailing list
Rpm-maint@lists.rpm
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/633#pullrequestreview-204967939___
Rpm
> And maybe it will be fair to add some mention about ALT experience of this
> behavior.
This was also behavior in OpenMandriva, too.
--
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-managemen
This is not exactly the first time this has come up. I recall that @proyvind
made a similar suggestion a few years ago in #107, though admittedly it was
more confusing then...
Speaking as someone who has implemented a frontend for sorting, the M:N
relationship that composition groups (or on the
@TomyLobo That is up to Red Hat (RHEL) and SUSE (SLE). File requests with them.
--
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/5455f02523a9b8583d5a942a6d97f1084f3093df#co
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/623#pullrequestreview-198892677___
Rpm
The idea has been bandied about before to migrate the "reason" info stored in
yumdb (now using SWDB in newer versions of DNF). I don't know what really holds
up a potential implementation of this in the rpmdb.
@dmach, @ffesti, @pmatilai: what do you guys think?
--
You are receiving this becaus
@marxin Could you please reword the commit message to include an explanation of
why you want 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/606#issuecomment-45268448
Conan-Kudo requested changes on this pull request.
NAK. If someone actually wants all the output, they can append it themselves,
especially since different Makefiles handle verbosity differently.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
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/613#pullrequestreview-189678463___
Rpm
Hmm, so according to [PEP
440](https://www.python.org/dev/peps/pep-0440/#compatible-release), this is
equivalent to `(pyramid >= 1.7 with pyramid < 2.0)`. So it's equivalent to `^`
in Rust and Ruby.
--
You are receiving this because you are subscribed to this thread.
Reply to this email direct
Conan-Kudo approved this pull request.
LGTM
--
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/615#pullrequestreview-187249075___
Isn't that what the `--quiet` switch is for...? I'm not sure this patch makes
sense...
--
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/615#issuecomment-449205132___
@pmatilai Now that RHEL 8 is on its way, could we consider dropping Lua < 5.3
compatibility in master?
@daurnimator Could you please rebase your PR on current master?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://
Won't we need an `rpmlib()` dependency emitted for source packages that have
`%elif`? Or do we just typically ignore this and let things explode on their
own?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
@nim-nim you could just do `%go_genbuildreqs`
--
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/593#issuecomment-443234813___
Rpm-m
@kalev unfortunately we need this change in stable branches before we can use
it in Rawhide. Doesn't mean we allow that to be used before a certain point,
but we still need it there.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Conan-Kudo approved this pull request.
Looks good to me and covers rich dep versions 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/597#pullrequestreview-177298957_
However, unlike most newer languages, the ones we have macros for in here are
also ones where rpm includes code for in its source tree.
Since we have Python bindings, I'd rather have us keep those macros in here...
--
You are receiving this because you are subscribed to this thread.
Reply to th
It is already the distributor's problem, since they have to build rpm and tell
it what the Python interpreter is.
--
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/508#issuec
@hroncok That doesn't preclude the default Python being set. I (ab)use this
fact for Pagure packaging in Fedora already.
And keep in mind that in exactly 1 year and 2 months, `/usr/bin/python` will
mean _only_ Python 3 anyway.
This is much ado about nothing.
--
You are receiving this because
Red Hat's indecision aside, pretty much everyone else knows how they're going
to have "default Python". And don't we have a `@__PYTHON@` substitution anyway?
It gets filled in with whatever is detected for the interpreter.
If you want to be fancy, just make it if `@__PYTHON@` isn't detected at b
@mlschroe Well, when we're referring to hg/git/svn snapshot dates, that's
considered as part of upstream versioning. This is done in openSUSE and we want
to move to that in Fedora to simplify automation of package (re)builds and
things like that.
--
You are receiving this because you are subsc
Conan-Kudo approved this pull request.
The changes look good, but here's a suggestion for the function name change.
> @@ -228,12 +228,12 @@ static rpmRC processScriptFiles(rpmSpec spec, Package
> pkg)
return rc;
}
-static int haveTildeDep(Package pkg)
+static int haveCharInDep(Package pk
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/597#pullrequestreview-175803053___
Rpm
@ffesti @ignatenkobrain Let's have a clearer name for the function, please?
Char does not mean carat to me. :)
EDIT: I'm dumb. This is a generalization of the tilde function.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ffesti @ignatenkobrain Let's have a clearer name for the function, please?
`Char` does not mean `carat` 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/597#issue
@ignatenkobrain I'm not against this, I'm just sad that bad versioning is a
thing.
--
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-439158203
You crush my soul. :cry:
--
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-439148281___
Rpm-maint mailing list
Rpm
@ignatenkobrain That's why you're supposed to do something like
`1.2+git20180101.deadbeef`, so that it sorts lower than `1.2.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/
Conan-Kudo commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
Yeah, but f
I don't have a problem with it if @pmatilai and @ffesti are okay with it.
But the filename should use a dash instead of a colon to avoid issues with
parsing file paths.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https:
That is effectively what OpenMandriva Lx3 does. And that's functionally saying
that it's part of the version comparison, because you've made it a property of
selecting a package.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on Git
@wladmis What do you mean by "build matching"? I'm not sure I understand what
you're saying here...
--
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/589#issuecomment-43761
Conan-Kudo commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
No one part
Conan-Kudo commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
@wladmis Ac
Conan-Kudo commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
The version
Conan-Kudo commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
@wladmis Al
Conan-Kudo commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
Do you real
Conan-Kudo requested changes on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
Why
> Still haven't gotten around to look this in any real detail, but here's
> another thought: why limit this to only buildrequires? One of the major
> shortcomings of the "new" dependency generator is the inability to generate
> package specific dependencies easily, and this looks like a nice gen
I don't prefer asciidoc, I think markdown is fine, but I just don't know why
anything special is needed for 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/issues/584#issu
Looks great 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/590#issuecomment-435613969___
Rpm-maint mailing list
Rpm-
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/590#pullrequestreview-171338460___
Rpm
Conan-Kudo requested changes on this pull request.
> @@ -102,6 +102,7 @@ Name: %{NAME}\n\
%|EPOCH?{Epoch : %{EPOCH}\n}|\
Version : %{VERSION}\n\
Release : %{RELEASE}\n\
+%|DISTTAG?{Disttag : %{DISTTAG}\n}|\
Please use `DistTag`
--
You are receiving this because yo
`%generate_` would be my vote
--
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/104#issuecomment-435050523___
Rpm-maint mailing l
You're basically trying to ask for a new input build recipe format without
actually directly saying it.
It would actually be easier to design a base input format that is YAML with
spec macro overloads then it would be to add brittle YAML to a shell oriented
spec file. That said, I'm personally
The _whole_ point of Markdown is that they are supposed to legible without
formatting. That is, it's typesetting that isn't awful and looks fine without
processing.
There's not a lot of reason I can see for introducing a weird tag for this,
especially since I can do things like paragraph breaks
I think probably the most sane format would be
`name[-[epoch:]version-[release[.disttag]]][.arch]`. That extends nicely and
overlays cleanly over most Linux distributions' usages of a DistTag.
In addition, I would expect that the DistTag would be part of the filename
format for both source and
You're basically asking for `BuildRecommends`?
--
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/577#issuecomment-431722842___
Rp
Well, for example, `-p2` doesn't work with most SCMs, but is valid for the
plain `patch` backend.
--
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/564#issuecomment-427673013
701 - 800 of 1213 matches
Mail list logo
