4.13.0.2 works.
--
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/672#issuecomment-484220430___
Rpm-maint mailing list
I've been very stupid and lost much time on this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #672.
--
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/672#event-2284310420___
Rpm-maint mailing list
The current `Provides`/`Requires` generation operates on a staging directory
tree simulating the target deployment. This is mostly fine, except it breaks
absolute symlinks within the staging directory. And, in some cases, those
symlinks (and their target) participates in `Provides`/`Requires`
Closed #657.
--
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#event-2281830004___
Rpm-maint mailing list
Everything what you need to do is to check what is going to be built during
%generate_buildrequires and filter that out.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It is a lot harder to create relative symlinks reliably in spec files,
especially when part of the creating is given to manual packaging. (I
simplified the example, you can have multiple levels of directories). The whole
point of the FHS is not to have to worry about relative locations.
--
@nim-nim
from `ln(1)`:
```
-r, --relative
create symbolic links relative to link location
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
%{unexpand:…} is not terrible, but it makes me think of unexpanding that has
already been expanded, which is not what it's about. %{body:...} has the
benefit that it's the same exact term we use in documentation, so people know
exactly what it is.
--
You are receiving this because you are
yes, but you know that SRPM is built in one environment while rest of packages
in others.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #655 instead, closing.
--
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/663#issuecomment-484001883___
Rpm-maint mailing
Do you have specific example where and how this should be used?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, supporting bad packaging practises is not a reason to get into the
container business. However people might not realize the implications of
absolute symlinks in packages, it's something we could add a warning for.
--
You are receiving this because you are subscribed to this thread.
Reply
Actually I think this is a perfectly legit request, it's not something you can
currently do regardless of how many %-escapes you add and not invasive at all.
Something along the lines of:
```
%{body:}
```
...but I'm not particularly happy about the name "body" so other suggestions
welcome.
The people who asked this just wanted to access the info computed by koji (or
mock or copr) in the produced rpm files, without needing to connect to koji
(or mock or copr)
Not to mention, than mock and copr do not archive all build roots they are
cleaned up regulartly, the only thing that
Closed #569.
--
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/569#event-2281819018___
Rpm-maint mailing list
Closed #572.
--
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/572#event-2281818977___
Rpm-maint mailing list
I think this has been long enough in waiting-for-info state. Closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think this has been long enough in waiting-for-info state. Closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This is wrong way to create symlink, you should always create relative ones. In
that case it will work both during build and during runtime.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I the current way Go sources are organised, a "provides" is a directory
containing Go source files. And projects are renamed all the time so it is
common to alias previous names by symlinks (or http redirects in github)
so you have things like
```
/usr/share/gocode/src/oldname →
and if you want to go with subpackage, you don't need any changes in RPM. Just
override %build/%install (whatever is generating debuginfo subpackages) and run
`rpm -qa` there. Although in some cases it won't work. This should be done by
mock, really.
--
You are receiving this because you are
Another thought on the subject is that we could have a brp-script that turns
absolute links into relative ones.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain you'll quickly see how inconvenient that is when you get to
compose multiple generators (as will happen eventually since multi-tech
projects do exist). There’s a good reason `Requires` delegate this filtering to
rpm, via `Provides`. It is real hard to do at the generator level
...and pondering over theoretical issues is not going to get us anywhere...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #665 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/665#event-2282068759___
Rpm-maint mailing list
I think you need to use some kind of Provides: bundled() and put there whatever
was used in buildroot. Doing this somewhere else doesn't worth it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #607.
--
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/607#event-2281823809___
Rpm-maint mailing list
Just put enough `%%` in there. It seems quite invasive change without much
benefit.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think this is quite complex thing, because once we get automatic subpackages
generation, you will face same problem as with BuildRequires generator... That
your sourcerpm is incomplete until you build whole thing
Not saying that it is impossible, but I don't see it very useful in
..and pondering over theoretical issues is not going to get us anywhere...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai `%{unexpand:…}`?
--
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/582#issuecomment-483977641___
Rpm-maint mailing
Sure, computing the list needs to be done by the build system, since it's the
system that actually assembles the build root. But the build system needs a way
to store the resulting list in one of the produced rpm files, since ultimately
only those files are lept long-term.
Unless I'm missing
I need to re-check why `-r` was not used, whether there is a good reason or if
it was just lost in the other breakage noise. Nevertheless that will only work
(if it works) for the symlinks we generate ourselves, not those produced by
upstream tools.
--
You are receiving this because you are
Closed #663.
--
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/663#event-2282076832___
Rpm-maint mailing list
ignatenkobrain commented on this pull request.
> * @return buffered stdout from script, NULL on error
*/
-static StringBuf getOutputFrom(ARGV_t argv,
-const char * writePtr, size_t writeBytesLeft,
-int failNonZero, const char
ignatenkobrain commented on this pull request.
> @@ -248,23 +248,24 @@ static rpmds rpmdsSingleNS(rpmstrPool pool,
* @param writeBytesLeft no. of bytes to feed to script on stdin
* @param failNonZero is script failure an error?
* @param buildRootbuildRoot directory (or NULL)
+ *
Consolidate umptheen copy-slop variants of the same readLine() construct into a
unified helper, port all simple cases to use it. parsePreamble.c has a couple
of readLine() uses that do more work than just add lines, that's left as an
exercise for another rainy day. Supposedly no functional
Extends #659
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/670
-- Commit Summary --
* Support optionally duplicating rpmfcExec() output to a stream
* Use rpmfcExec() for executing all build scripts to simplify code
*
```
⋊> ~/P/f/r/meson on master ⨯ rpm -qpR
/home/brain/Projects/fedora/rpms/meson/noarch/meson-0.50.1-1.fc31.noarch.rpm |
wc -l 13:39:52
10
⋊> ~/P/f/r/meson on master ⨯ rpm -qpR
ignatenkobrain commented on this pull request.
> * @return buffered stdout from script, NULL on error
*/
-static StringBuf getOutputFrom(ARGV_t argv,
-const char * writePtr, size_t writeBytesLeft,
-int failNonZero, const char
@Conan-Kudo @ignatenkobrain @soig @scop @proyvind ?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
One major issue here is that setting up containers/chroots/whatever typically
requires root privileges. The build process is run as an unpriviledged user for
a reason. Yes, rpmbuild could drop privileges but not even handnig them out is
much more secure.
--
You are receiving this because you
Quote/quoting is something entirely different (we already have %{quote:...} btw)
Still thinking %{body:..} is the least worst so far.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
What about "literal", "quote" or "quoted"?
--
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/582#issuecomment-484037803___
pmatilai commented on this pull request.
> * @return buffered stdout from script, NULL on error
*/
-static StringBuf getOutputFrom(ARGV_t argv,
-const char * writePtr, size_t writeBytesLeft,
-int failNonZero, const char
I would like to have it licensed as the rest of RPM stuff (IIRC GPLv2+), but
I'm fine with whatever @ffesti or @pmatilai come up.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
In Golang packaging (Fedora), the -devel subpackages are computed by a Lua
macro called gopkg.
In rpm 4.14.2, if I try to rpmbuild the SPEC containing such macros and a
scriptlet, I get:
```
error: line 41: %pretrans devel -p
: package golang-github-hashicorp-cleanhttp-devel does not exist
```
48 matches
Mail list logo
