Also, I believe that `--rpmfcdebug` rpmbuild option should be mentioned in the
documentation.
--
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/1011#issuecomment-575106293_
> It's always been one per line, but added a note about that to the doc now.
I don't think this is correct neither comprehensible.
Let me use RubyGems requires generator as an example.
If I understand the generators correctly, the generator is called, when the
files are processed for the (sub)p
It will definitely break something, probably a lot of things. OTOH, it would
probably make the things more consistent, e.g. it would avoid issues such as
[[1]], because one would need to delete the file instead of excluding it.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=878863
--
You are
If there was macro `%repelace_text_in_file_inplace` which would have defined
output, I could see a benefit. But claiming that `sed -i` is not universal and
replacing it with macro `%__sed_i` does not make any sense to me.
--
You are receiving this because you are subscribed to this thread.
Repl
I would probably prefer `add`/`remove` combination, which would be more work on
one side, but IMHO better then "replace by nothing" to remove flag.
But I like the idea.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https:
Thx for the reference. I'd still appreciate some improvement here, because the
behavior is confusing.
--
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/793#issuecomment-521
Well, I'd blame the RPM multithreading modifications, that is why I have
reported it 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/794#issuecomment-512151926_
Actually there was thread about this on fedora-devel:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/6LHINQVZYABXBKAEN3BQ25JPMB5FYEI2/
CC @hroncok
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@xsuchy any idea?
--
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/794#issuecomment-511684798___
Rpm-maint mailing list
Rpm-main
Recently, presumably since RPM 4.15.0.beta.1 landed in Fedora Rawhide, the
rpmbuild output is garbled. E.g.:
~~~
... snip ...
1)
Process.clock_getres matches the clock in practice for
Process::CLOCK_PROCESS_CPUTIME_ID FAILED
Expected 1
not to equal 1
/builddir/build/BUILD/ruby-2.7.0-0c6
When I build package, I get following errors:
~~~
... snip ...
error: Installed (but unpackaged) file(s) found:
/usr/lib/debug/usr/lib64/ruby/enc/trans/cesu_8.so-2.7.0-0.1.git0c6c937904.fc31.x86_64.debug
/usr/lib64/ruby/enc/trans/cesu_8.so
/usr/share/ruby/logger/errors.rb
/usr/share/
I don't think I have anything to override, because I would need to have the
*.attr file installed. I can define the `%__ruby_provides` but is it really
that easy? I'd be surprised. Why we would need to have the *.attr file then?
--
You are receiving this because you are subscribed to this threa
It would be very handy, if the dependency generators shipped by package could
be used during build already.
E.g. when we build ruby package, it builds rubygems-devel package, which ships
generators for rubygem- packages. But it also provides dozen of rubygem-
subpackages and it would be very ha
I just wonder, if RPM could provide some facilities to create the directory
structure in more flexible way.
Currently, the filesystem package in Fedora has ~1MB. That is quite a lot.
Installing the package, it probably consumes even more inodes. I just wonder,
if there was a way for RPM to know
Just FTR, there is already precedent in software collections, where `_root_`
prefix [[1]] is used for the same purpose. It would be nice to reuse this
prefix instead of coming with new one.
[1]:
https://www.softwarecollections.org/en/docs/guide/#sect-Macros_Not_Specific_to_a_Software_Collection
I just wonder, how this influences the console output. Will it be still always
readable or will there happen some output race conditions and it won't be
readable anymore?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
http
> rpm cannot make assumptions about it being packaged.
I could imagine that assumption about being available/installed was useful (but
then the file would have to be shipped by RPM itself), but I can't see what is
this assumption good for?
--
You are receiving this because you are subscribed
> Why does every single programming language have a built-in path for looking
> up includes/imports instead of using a hardcoded path?
But then every single programming language allows to extend the search paths,
which is not part of this proposal apparently.
Also every programming language sup
Thinking about this, I am not sure this provides any benefit. If I have to have
the include explicitly in the .spec file, then I don't know why I should not
have it including full path, because this must be documented somewhere anyway.
Why for example Ruby should put some "include" file into RPM
> > I wish `%_rpmincludedir` was externaly configurable somehow, e.g. by env
> > variable or cmd line option. Otherwise it will make life harder to SCLs,
> > where everything should go into /opt.
>
> It's a macro. You can --define it to whatever you like.
Oh, yes, probably. But is there way to
I wish `%_rpmincludedir` was externaly configurable somehow, e.g. by env
variable or cmd line option. Otherwise it will make life harder to SCLs, where
everything should go into /opt.
What is the use case anyway? I can imagine using this for including
pre-generated changelogs, but again, it wou
There is typo in the description which probably comes from
a5ca92f06cbbfd70cec08a87a376ef8c369e00a6 commit message: s/can now we replaced
with/can now be replaced with/
Also, it would be useful to explain how the patches are applied. Is the
%autosetup required? Or should they by applied one by
Given the proposed syntax, which looks ugly in all cases, I'd prefer to forget
about the ternary operator in RPM and focus on other important issues of 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/
Closed #570.
--
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/570#event-1903751425___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Ah, thx for pointing #463 out.
--
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/570#issuecomment-429805198___
Rpm-maint mailing
Coming from this \[[1]\] discussion, I think it would be nice if .spec file
could store checksum of sources used to build the package.
Currently, using-dist git, the hashes are stored in separate "sources" file.
But there is no reason, why these checksums should not be stored directly in
RPM. T
Just two ideas:
1. What if there was something like begin, ensure, end block? I.e. I could
ensure that the executed process is really terminated, although the test suite
failed.
2. What if I could somehow register/execute some process in background using
some RPM framework? I.e. RPM would be aw
If I remember correctly, I met this issue running rpmbuild inside mock, which
is actually using systemd-nspawn, which complained during the container
shutdown. Moreover, I think that systemd-run is not available inside mock, so I
am not convinced this is the right solution.
--
You are receivin
> Then invoke rpmbuild with --macros, appending your patterns at the end of the
> colon separated list.
How can I use --macros parameter in Koji? Why should I explain how to use
--macros parameter to users of SCLs when it would not be necessary with env
variable?
> Alternatively, choose known
I am looking for a way to tell RPM that there might be some paths which might
contain arbitrary macro files. If such files are located, they should be loaded
by RPM.
IOW given there is metapackage like this \[[1]\] and I have installed
rh-ruby22-runtime package and I call ```scl enable rh-ruby2
I am not surprised at all that the wildcard is not supported. I am just
surprised I am suggested to use ```%load``` where it is not usable in its
current form.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.
Of course, that was just test. So I did different one:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..ecc5e93 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -102,8 +102,7 @@ Source14: test_systemtap.rb
# The load directive is supported since RPM 4.12, i.e. F21+. The build process
This passes:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..3748781 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -104,6 +104,7 @@ Source14: test_systemtap.rb
# fails on older Fedoras.
%{?load:%{SOURCE4}}
%{?load:%{SOURCE5}}
+%{?load:%{_rpmmacrodir}/macros.*}
# Fix ruby_version
Just quick test:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..fc2e68b 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -104,6 +104,7 @@ Source14: test_systemtap.rb
# fails on older Fedoras.
%{?load:%{SOURCE4}}
%{?load:%{SOURCE5}}
+%{load:%{_rpmmacrodir}/*}
# Fix ruby_version abu
Ok, so I can imagine I put this into every SCL meta package, but then I have a
few questions.
* Does the load macro support the wild cards?
* What happens if there is no such macro file? Does it fail or just continue?
--
You are receiving this because you are subscribed to this thread.
Reply to
I am disappointed. Many people calls SCL being big hack, but you won't make it
any easier :(
So if I read it correctly, the suggestion is that scl-utils should put
something into ```%{_rpmmacrodir}``` (please note that the collection itself
are generally not allowed to put anything outside thei
Of course some distributions found their way despite RPM upstream being
reluctant to support this or similar feature. The #69 just proves that. I did
not mentioned Fedora anywhere and I don't think that #69 was proposed by Fedora
people.
--
You are receiving this because you are subscribed to
Well, one big advantage from the %include/%changelog way would be the possible
opt-in. If you want to automate "slapping the changelog itself at the tail of
the spec", then it means you have to actually change the build infrastructure
to do it.
TBH the biggest issue I see currently is that the
Actually, if ```%include``` automatically included the referenced file into
SRPM, that would be helpful as well. I realize, that the path could be
arbitrary, but if there was restriction, that could work ...
--
You are receiving this because you are subscribed to this thread.
Reply to this emai
Currently, the changelog entries can be either listed in a .spec file or they
could be included by ```%include``` directive. However, usage of the
```%include``` has one major downside, that the included file must be
explicitly listed as one of sources, otherwise the file would not be available
@n3npq Good to see that extending RPM to support env variable shouldn't be
hard, since RPM has the --macros CLI option alrady.
@Conan-Kudo It might be risky, but we are doing it anyway. This is request to
do it a bit better way then we are doing it now. It would even improve the
situation, sinc
> In Mageia, this is done differently: the shebang is left as it, but the auto
> requires is translated from "/bin/env" to "/bin/foo".
This is interesting idea. Perhaps that could make @remicollet happier?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
> aha, this makes sense.. what do you think if there will be some macro which
> would accept regex and not mangle those files? something like
> __brp_mangle_shebangs_exclude_from
Yes, something like that would be useful ... what about __shabangs_excluse_from?
--
You are receiving this because
>> 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 inst
I remember people were using ```BuildRequires(check)``` until this syntax was
prohibited (this might be hint for BZ query 😄)
--
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
Since this was introduced into glibc just less then two years ago \[[1]\], I'd
expect the commit message to be more elaborate about reasoning, backward
compatibility etc.
[1]: https://sourceware.org/glibc/wiki/Proposals/C.UTF-8
--
You are receiving this because you are subscribed to this threa
> There's a certain difference between build-time scriptlets and install-time
> scriptlets, please try to be specific which ones you're talking about.
Not sure what you mean? Is that because you can choose interpreter of the
install time scripts while you can't do it for build time scripts?
Eit
I agree with @ffesti, i.e. I'd keep expanding the macros in scripts as they are
expanded now and wouldn't expand the rest of macros.
(OT: Actually it'd be nice if there is a way how to mark begin-end (especially
end) of the script )
--
You are receiving this because you are subscribed to
%mutable and %mutable(noreplace) ? :)
--
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/152#issuecomment-278896191___
Rpm-maint m
Just yesterday, I had usecase for this.
I am packaging updated Vagrant and there is used "plugin.json" file. We used to
store it in ```%{_datadir}/vagrant/plugin.json``` and it used to be ghost file.
But upstream changed some internals and now it is not possible to convince
Vagrant to use the f
But honestly, I am no sure why/how this should be handled on RPM side ...
--
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/134#issuecomment-275837496___
This is the use case:
http://pkgs.fedoraproject.org/cgit/rpms/rubygem-mongo.git/tree/rubygem-mongo.spec#n79
Please note it works just fine with rpm build or when using mock with
(--old-)chroot on the backend
--
You are receiving this because you are subscribed to this thread.
Reply to this ema
I am not user of %auto{patch,setup} but I hate the backup files around. I
really don't see any reason for their existence. And I saw quite some packages
shipping them accidentally ...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it o
Dne 1.11.2016 v 10:26 Pascal Terjan napsal(a):
> On 1 November 2016 at 09:01, Vít Ondruch wrote:
>>
>> Dne 1.11.2016 v 09:08 Pascal Terjan napsal(a):
>>> On 1 November 2016 at 07:53, Vít Ondruch wrote:
>>>> Dne 1.11.2016 v 00:04 Pascal Terjan napsal(a):
&
Dne 1.11.2016 v 09:08 Pascal Terjan napsal(a):
> On 1 November 2016 at 07:53, Vít Ondruch wrote:
>>
>> Dne 1.11.2016 v 00:04 Pascal Terjan napsal(a):
>>> One big problem with having the gemspec in the parent directory is
>>> that we can't easily apply
Dne 1.11.2016 v 00:04 Pascal Terjan napsal(a):
>
> One big problem with having the gemspec in the parent directory is
> that we can't easily apply patches to it.
You are right. Never thought about it. But I would not call it "big"
problem ;)
> This is a problem for about a dozen packages with i
Dne 17.10.2016 v 16:34 Pascal Terjan napsal(a):
> On 17 October 2016 at 15:12, Vít Ondruch wrote:
>>
>> Dne 17.10.2016 v 15:37 Pascal Terjan napsal(a):
>>> On 17 October 2016 at 14:31, Vít Ondruch wrote:
>>>> Dne 17.10.2016 v 15:07 Thierry Vignaud napsal(a
Dne 17.10.2016 v 15:37 Pascal Terjan napsal(a):
> On 17 October 2016 at 14:31, Vít Ondruch wrote:
>>
>> Dne 17.10.2016 v 15:07 Thierry Vignaud napsal(a):
>>> On 17 October 2016 at 12:06, Vít Ondruch wrote:
>>>> Dne 17.10.2016 v 11:30 Thierry Vignaud napsal(a
Dne 17.10.2016 v 15:07 Thierry Vignaud napsal(a):
> On 17 October 2016 at 12:06, Vít Ondruch wrote:
>> Dne 17.10.2016 v 11:30 Thierry Vignaud napsal(a):
>>> On 17 October 2016 at 10:10, Panu Matilainen
>>> wrote:
>>>>> What is the chance to get
Dne 17.10.2016 v 11:30 Thierry Vignaud napsal(a):
> On 17 October 2016 at 10:10, Panu Matilainen wrote:
>>> What is the chance to get [1, 2] into the release? I mildly remember,
>>> that once I was offered to get this patch into Fedora, but that never
>>> materialized and now it is almost a year
Hi Panu,
What is the chance to get [1, 2] into the release? I mildly remember,
that once I was offered to get this patch into Fedora, but that never
materialized and now it is almost a year. I don't think this is
controversial change which should make anything break.
Thx for considering.
Vít
My preferred way would be something like:
```
%changelog
%include changelog.txt
```
---
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/69#issuecomment-223894319___
Dne 28.11.2015 v 14:37 Neal Gompa napsal(a):
> On Thu, Nov 26, 2015 at 5:20 AM, Florian Festi <mailto:ffe...@redhat.com>>wrote:
>
> On 11/19/2015 04:09 PM, Vít Ondruch wrote:
> > What is the usecase for this? Isn't this just feature bloat?
>
>
What is the usecase for this? Isn't this just feature bloat?
Vít
Dne 19.11.2015 v 15:35 Neal Gompa (ニール・ゴンパ) napsal(a):
>
> 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 script
Thank you.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/27#issuecomment-156077796___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Dne 6.2.2014 13:50, Florian Festi napsal(a):
> Hi!
>
> While discussing updates and version-in-package-names issues (related to
> a programming language that shall not be named) we came up with the
> following (completely not thought through) idea:
>
> Offer a special character for separating the v
Dne 4.2.2014 18:14, Panu Matilainen napsal(a):
> On 02/04/2014 05:42 PM, Vít Ondruch wrote:
>> Dne 28.1.2014 08:12, Vít Ondruch napsal(a):
>>>
>>>
>>> #866: %include macros.foo
>>> --+---
Dne 4.2.2014 16:42, Vít Ondruch napsal(a):
> Dne 28.1.2014 08:12, Vít Ondruch napsal(a):
>>
>> #866: %include macros.foo
>> --+-
>>
>> Reporter: vo.x | Owner: RpmTickets
>&
Dne 28.1.2014 08:12, Vít Ondruch napsal(a):
>
>
> #866: %include macros.foo
> --+-
>
> Reporter: vo.x | Owner: RpmTickets
> Type: defect | Status: closed
> Priority:
Dne 19.12.2013 14:28, Panu Matilainen napsal(a):
On 12/18/2013 08:55 PM, Mimi Zohar wrote:
Hi Panu,
I'm interested in using the new plugin architecture for adding
'security.ima'
extended attributes. So far, I've cloned the rpm git repo, compiled and
installed it, with plugins enabled. For the
Dne 12.4.2013 13:53, Vít Ondruch napsal(a):
We are able to ensure, the either one or both Ruby implementations
will be installed on the system using virtual provide, such as
"Requires: ruby(release)", but in RPM there is currently no way how to
specify, that rubygem-nokogiri-m
Hi,
In February, I attended Developer Conference [1] and I saw interesting
presentation by Michael Schröder [2, 3]. What was the most interesting
part for me are the AND dependencies (slides 6/7 [2]) and I'd really
love to see support for them in RPM. Let me show you my use case.
There are t
201 - 272 of 272 matches
Mail list logo
