If an env-shebang is left alone then it's not right to filter /bin/env out of
the dependencies because env is then needed for running too. The reason rpm
doesn't generate dependencies for env-shebangs is that it can't be sure about
the path. There was a ticket on the old rpm.org trac instance, p
In case above is not acceptable, this code can be used instead
%define py_prefix %(echo `python -c "import sys;
sys.stdout.write(sys.prefix)"`)
but I don't know if .attr files can handle above macro.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@pmatilai Would it be possible to have these 4 patches applied to the latest
rpm built for Fedora 26 and later?
--
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/333#issuec
Transifex has wrong plural forms for Polish that they refuse to change.
Now that RPM ditched Transifex, we can fix it.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/347
-- Commit Summary --
* Update Polish plural forms
--
I have used the same macro from pkgconfig.attr.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/346
-- Commit Summary --
* Replace hardcoded path with _libdir macro as done in pkgconfig.attr. Add
-- File Changes --
M f
On 2 November 2017 at 15:24, Thierry Vignaud
wrote:
>
> On 2 November 2017 at 00:05, Igor Gnatenko
> wrote:
>
>> This might look too magic, but what it does in short:
>>
>>- Replace /usr/bin/env foo with /usr/bin/foo.. One could argue on
>>this, so we could add some macro to disable this
>>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?
Yes, auto-dep on the default interpreter make sense.
--
You are receiving this
> 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
Test for ctermid() in configure script instead of using OS define.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/345
-- Commit Summary --
* Test for ctermid() existence.
-- File Changes --
M configure.ac (1)
M lu
@zoujiaqing If you want to avoid that issue, you can try using beecrypt crypto
backend instead of NSS.
--
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/340#issuecomment-34
> In Mageia, this is done differently: the shebang is left as it, but the auto
> requires is translated from "/bin/env" to "/bin/foo"
I think this is wrong approach. Because now try `ln -s /bin/falsh ~/bin/foo`
and run your script... /bin/env is not acceptable for packages.
--
You are receivi
@soig I personally don't think it's a good idea to eliminate file deps, as once
you use package names, they get more distro-specific. For example, `perl-base`
is a Mageia-only thing.
But that said, perhaps we want to support both (translating the dependency to
the correct file dep from the inte
On 2 November 2017 at 00:05, Igor Gnatenko wrote:
> This might look too magic, but what it does in short:
>
>- Replace /usr/bin/env foo with /usr/bin/foo.. One could argue on
>this, so we could add some macro to disable this. In Fedora it is even
>prohibited by guidelines now. This br
@daurnimator Generally speaking, subtrees/submodules aren't really acceptable.
And we don't usually vendor in libraries.
That said, maybe @pmatilai might make an exception for the Lua stuff, I don't
know...
--
You are receiving this because you are subscribed to this thread.
Reply to this emai
I explained a whole pile of things that you could do to help your cause in
https://github.com/rpm-software-management/rpm/pull/260#issuecomment-339914006,
how about starting with those?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
The v2 is here, I didn't add _exclude_from so far because of 1) templates are
non-executable and we don't mangle such files anymore 2) it is not trivial to
implement because it happens in shell which has a bit different semantics of
regexps than RPM has
--
You are receiving this because you ar
Hmm, I seem to be misremembering: almost none of the existing ones either
upstream or Fedora have disablers. So leave it out for now, I dont want to grow
fifteen different styles of disabling that people then will be relying on.
--
You are receiving this because you are subscribed to this threa
@pmatilai yeah, I remember reading #122, but I am probably not the one who
wants to improve brp mechanism right now (e.g. implementing some classifiers as
we have for dependency generators). And I will add enable_disable thing shortly.
--
You are receiving this because you are subscribed to thi
Thanks for the patch!
--
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/343#issuecomment-341350461___
Rpm-maint mailing list
Rpm-ma
Merged #343.
--
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/343#event-1322505544___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
Haven't really looked / thought about it, just commenting on general level. For
one, anything like this will require a way to disable because somebody *will*
run into something unexpected. And that brings us back to PR #122 ...
--
You are receiving this because you are subscribed to this threa
@pmatilai thanks, I will remove it.. Should I keep some warning?
Do you have any opinion on other functionality included in brp script? Also
what's your opinion on naming & idea of excluding files from mangling?
--
You are receiving this because you are subscribed to this thread.
Reply to this
> __shabangs_excluse_from
You are too drunk 🍷 🍺 🍻 🍸
--
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/344#issuecomment-341348817__
> 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
I would leave non-executable files alone. A shebang in a non-executable file
can be simply considered to be a comment, it does no harm by existing.
--
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
> For me it is generators. What would you do with file like this:
>
> https://github.com/bundler/bundler/blob/master/lib/bundler/templates/Executable
>
> Should it have executable bit or not? Should you remove the shebang?
>
> There are some other examples in the directory:
>
> https://github.c
>> 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
27 matches
Mail list logo
