Is there any solution to fix the problem? If not, can we consider adding
information description in rpm?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1266#issuecomment-1333121955
You are receiving this because you are subscribed to t
I mean, rpm can consider copying lead instead of regenerating lead which seems
can be worked fine.
The other way, I think we can add documentation to explain it, because few
people pay attention to lead and lead has no actual effect, so it is OK not to
modify it.
Is there any other good way？@pm
Right, you can cut & paste the library. And then there is a bug and you need to
update all your spec files. Scales really well.
The execute is not there forever:
```
execute(path [, arg1 [,…])
Execute an external command (rpm >= 4.15.0) This is handy for executing
external helper commands witho
Also, in specs, macros (including Lua) are just a fancy text pre-processor.
That puts the expectations into some kind of context.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332325736
You are receiving this becaus
The posix module is there since forever and lets you handle that kind of stuff.
Also, for capturing output you can just use rpm macro functionality, which is
usable from Lua.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issueco
For libraries written in Lua, you could copy the code into your spec file.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332310497
You are receiving this because you are subscribed to this thread.
Message ID: __
Like rpm.execute is 4.15+ so I cannot rely on that, need a library.
Capturing the output is not supported at all, need a library.
The lua standard library handles execution by shell but not quoting of
arguments (for security of rpm !!!), need a library.
--
Reply to this email directly or view
The problem is more general, though.
Lua in itself provides very little functionality without any libraries.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332293665
You are receiving this because you are subscribed
For one I would like to have the Lua inspect library available.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332291462
You are receiving this because you are subscribed to this thread.
Message ID: _
That doesn't answer the question: what are you trying to do?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332253820
You are receiving this because you are subscribed to this thread.
Message ID:
> No idea why my browser doesn't show the ~~sub script~~ but it should
> according to the markdown syntax.
Well, it was not **sub-scripted**, but **~~struck out~~**, though
never mind.
The web-browser I use(d) is Firefox ESR; presumably Firefox is a quite common
denominator.
> Anyway, thanks
I want to use lua in a rpm spec file.
lua provides very limited capabilities out of the box so I need libraries to do
pretty much anything.
With this limited search path I cannot use libraries that are already provided
by the system.
--
Reply to this email directly or view it on GitHub:
https
Yes, it's a poor design from the nineties. It's getting a little out of scope
as well.
Rpm ships with the extensions that are expected to be needed in the very
specific context of rpm already. Now, if you want something constructive to
come out of this, you could explain what it is that you're
Also it's bad design on RPM's part that when rpm crashes the whole transaction
is lost.
Have you ever heard of power outage?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332225748
You are receiving this because yo
And what use is lua exactly if you cannot load any libraries?
The language is designed for embedding and is very simplistic which means that
it relies on libraries for pretty much anything.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issu
@hramrach the RPM Lua environment is an in-process interpreter. If it breaks in
an unrecoverable way, librpm dies, which kills the whole transaction. It was
never intended to be extensible at runtime for this reason.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-s
Closed #2309 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#event-7922500112
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint ma
Yes, and loading is what you'd like to do. Which is exactly the problem.
There are various safeguards to protect the rpm Lua environment in place
already, many more needing to be added.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2
How would the rpm process crash?
It requires that a user script loads a library, it cannot crash based on the
sole existence of a library.
The load path can be altered from the script anyway, it's just tedious.
Meaning that this does not in practice prevent use of libraries, only makes the
use
Preventing people from using arbitrary libraries from within rpm is exactly the
thing we want to prevent, and which is why the path is the way it is. Seems
we've missed the C library path though.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rp
Crashing the RPM process and potentially bricking someone's installation is not
acceptable, and that's what would happen if someone screwed up this without
safeguards in place.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issue
Sorry, I don't get what the problem is.
You can explicitly load a lua module, and then it will be searched in the load
path.
If you exclude the standard search path it means that already installed lua
libraries cannot be explicitly loaded when lua code is running in rpm. That
sounds like a bug
Also RPM Lua can be used for scriptlets at install-time, and we have no safe
way to handle dependencies for that right now (@michel-slm is working on Lua
module packaging and dependency generators, which may allow us to revisit that
eventually).
--
Reply to this email directly or view it on Gi
We have custom RPM Lua API extensions in the interpreter environment, and
custom versions of some modules integrated as well. If this worked before, that
was almost certainly a mistake and it shouldn't.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manage
What is 'average lua interpreter'?
It's based on liblua, it's the same interpreter as any other.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332182236
You are receiving this because you are subscribed to this thr
The real bug here may well be that we're looking for the C libraries.
Lua in rpm is not your average Lua interpreter, and we don't want people
pulling in arbitrary extensions that may do whoknowswhat.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manageme
What 'stuff' would conflict, specifically?
Why does it not conflict when it's written in C but it does conflict when
written in Lua?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332168380
You are receiving this be
There are zero plans involving luajit.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1377#issuecomment-1332165039
You are receiving this because you are subscribed to this thread.
Message ID: __
This is by design, as RPM Lua is not _exactly_ a pristine Lua environment and
some stuff would conflict with what RPM Lua provides.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332164363
You are receiving this beca
lua5.1 -l 'foobar'
lua5.1: module 'foobar' not found:
no field package.preload['foobar']
no file './foobar.lua'
no file '/usr/local/share/lua/5.1/foobar.lua'
no file '/usr/local/share/lua/5.1/foobar/init.lua'
no file '/usr/local/lib/lua/5.1/foobar.lua'
To be clear: luajit maintenance is not doing well - it was abandoned, forked,
then the maintenance of the original resumed but patches from the fork have not
been merged back. The JIT works on x86, Arm, and ppc32 but pretty much nothing
else. Specifically s390 and ppc64 was implemented at some p
Which is not available on most architectures.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1377#issuecomment-1332141570
You are receiving this because you are subscribed to this thread.
Message ID: ___
I don't understand this. Do you want me to use something different than
rpmsign? Because rpmsign used to copy the lead, but commit
3255273ae0fabd03c9738249a29c9c1e15f28f64 changed it to regenerate the lead
instead of copying over.
--
Reply to this email directly or view it on GitHub:
https://
> See the comment in rpmLeadFromHeader (as I wrote):
>
> ```
> /* FIXME: should grab these from header instead (RhBug:717898) */
> rpmGetArchInfo(NULL, &archnum);
> rpmGetOsInfo(NULL, &osnum);
> ```
>
> So you'll get the arch from the host where you created or deleted a
>
> copies over the lead data verbatim when creating or deleting signatures
Thanks for the reply, I know what you mean, this does seem to be a problem. But
why not consider copying the lead data word for word when creating or deleting
signatures? Is there any other problem?
--
Reply to this emai
See the comment in rpmLeadFromHeader (as I wrote):
```
/* FIXME: should grab these from header instead (RhBug:717898) */
rpmGetArchInfo(NULL, &archnum);
rpmGetOsInfo(NULL, &osnum);
```
So you'll get the arch from the host where you created or deleted a signature,
and not th
The arch element does not exist because the name in rpmlead_s is obtained from
`headerGetAsString(h, RPMTAG_NEVR)` in rpmLeadFromHeader and arch element is
not saved. In addition, 3255273ae0fabd03c9738249a29c9c1e15f28f6 seems fine, and
I don't quite understand how the arch element is changed.
FWIW, ctest does seem capable of doing the kind of thing we do, it's just
(again) very non-obvious from the ctest/add_test() documentation. One needs to
use properties to tell it what to expect,
https://stackoverflow.com/questions/19435375/simple-integration-testing-using-bash-with-cmake-and-cte
when I install dbus-daemon,install dbus-daemon before install shadow.so
report useradd and groupadd command not found，and installtion failed. can I add
shadow to setup.rpm 'Requires'? or can from rpm to solve this issue
--
Reply to this email directly or view it on GitHub:
https://github.com/
Ugh... I stand corrected. What scl-utils uses is CMocka, not ctest. Apologies
:laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2098#issuecomment-1331924279
You are receiving this because you are subscribed to this thread.
Mes
Yup, ctest is nice but I think it's better suited for unit testing, whereas
what we need here is CLI testing. Anyways, to get an idea of how cmake
looks/works, one does not need to go too far:
https://github.com/sclorg/scl-utils/tree/master/tests :smile:
--
Reply to this email directly or vie
Reminds me of: https://i.redd.it/icdv9tg5eyt61.jpg :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2308#issuecomment-1331824807
You are receiving this because you are subscribed to this thread.
Message ID: ___
No idea why my browser doesn't show the sub script but it should according to
the markdown syntax.
Anyway, thanks for the fixes!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2306#issuecomment-1331818325
You are receiving this because
Merged #2306 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2306#event-7919782713
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint maili
Thanks for the fix!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2308#issuecomment-1331809694
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint maili
Merged #2308 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2308#event-7919726606
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint maili
> I think we should update the documentation to indicate what it actually does
> (`%attr` overrides `%defattr`, it doesn't indicate it won't change anything).
Do you want to express %defattr overrides %attr?
I think we can consider %attr overwriting %defattr, and this problem seems to
be solved
47 matches
Mail list logo
