I have not been able to determine if librpm is thread-safe. From looking at
the code, it appears not to be, for several reasons:
- librpm changes global state, such as the process umask.
- Lua scripts can change the environment, which can race with access to the
environment from other threads.
@pmatilai the large file format / PAYLOADDIGESTALT is a good idea for
constructing original format rpms that most clients can use. I will spend more
time thinking about it.
@mlschroe I agree that there should be some way to tell RPM that a(n original)
rpm file already passed verify locally. I
@Conan-Kudo That is fantastic news!
--
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/1482#issuecomment-758096633___
Rpm-maint
@DemiMarie The first steps towards making it possible to do that are being done
now: https://pagure.io/koji/pull-request/2637
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@DemiMarie commented on this pull request.
> + lua_settop(L, 1);
+ rc = rpm_expand(L);
+ }
+}
+return rc;
+}
+
+static int mc_newindex(lua_State *L)
+{
+rpmMacroContext *mc = checkmc(L, 1);
+const char *name = luaL_checkstring(L, 2);
+if (lua_isnil(L,
@mlschroe tell that to the Fedora infrastructure maintainers. They don’t sign
their metadata.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The LGTM alert is a false positive: the dead code is a static assertion, so it
is a no-op at runtime anyway.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(Just FYI: libzypp will support posttrans file triggers soonish. So you could
use that to do the info install after the uninstall.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
At least for `%filetriggerun`, the hardcoded `0` as argument actually makes it
really dangerous to use properly, as it is also run when the package containing
the trigger is uninstalled/upgraded from. The issue is that the
`%filetriggerun` is called after the new package's `%filetriggerin`, so
@pmatilai commented on this pull request.
> +
+As a special case, `BuildArch: noarch` can be used on sub-package
+level to allow eg. documentation of otherwise arch-specific package
+to be shared across multiple architectures.
+
+ Prefixes
+
+Specify prefixes this package may be installed
@pmatilai commented on this pull request.
> + lua_settop(L, 1);
+ rc = rpm_expand(L);
+ }
+}
+return rc;
+}
+
+static int mc_newindex(lua_State *L)
+{
+rpmMacroContext *mc = checkmc(L, 1);
+const char *name = luaL_checkstring(L, 2);
+if (lua_isnil(L,
Rpm will have to support the embedded signatures for just about forever more,
but there's no reason rpm couldn't support detached signatures as an
alternative, it's just a piece of OpenPGP data that could come from anywhere if
there was an API for it. But detached signatures aren't any magic
@Conan-Kudo commented on this pull request.
> +
+As a special case, `BuildArch: noarch` can be used on sub-package
+level to allow eg. documentation of otherwise arch-specific package
+to be shared across multiple architectures.
+
+ Prefixes
+
+Specify prefixes this package may be installed
@pmatilai commented on this pull request.
> +Specifies the architecture which the resulting binary package
+will run on. Typically this is a CPU architecture like sparc,
+i386. The string 'noarch' is reserved for specifying that the
+resulting binary package is platform independent. Typical
Not that rpm cares about the case (it doesn't) but adjusted to the commonly
used casing now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
00283b1e079bd3b04dca8b811de61a9dc70a52c9 fixup! Add bunch of docs on spec tags
and file virtual attributes
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai commented on this pull request.
> +
+ Exclusivearch
+
+Package is only buildable on architectures listed here.
+For example, it's probably not possible to build an i386-specific BIOS
+utility on ARM, and even if it was it probably would not make any sense.
+
+ Excludeos
+
@pmatilai commented on this pull request.
> +
+Package is only buildable on OS'es listed here.
+
+ Buildarchs
+
+Specifies the architecture which the resulting binary package
+will run on. Typically this is a CPU architecture like sparc,
+i386. The string 'noarch' is reserved for
@pmatilai commented on this pull request.
> @@ -169,8 +169,8 @@ rpmRC rpmpkgRead(struct rpmvs_s *vs, FD_t fd,
goto exit;
}
-/* Read the signature header. Might not be in a contiguous region. */
-if (hdrblobRead(fd, 1, 0, RPMTAG_HEADERSIGNATURES, sigblob, ))
+/* Read
@DemiMarie commented on this pull request.
> @@ -169,8 +169,8 @@ rpmRC rpmpkgRead(struct rpmvs_s *vs, FD_t fd,
goto exit;
}
-/* Read the signature header. Might not be in a contiguous region. */
-if (hdrblobRead(fd, 1, 0, RPMTAG_HEADERSIGNATURES, sigblob, ))
+/* Read
This pull request **introduces 1 alert** when merging
71842ad20cccadd907f7a345d2101c203a97490c into
5ce2b5e3121aa07eb1ccf2bc24443c1536bf94d5 - [view on
LGTM.com](https://lgtm.com/projects/g/rpm-software-management/rpm/rev/pr-09a8b39359d616c6e625afffb647f96d79c4f7a5)
**new alerts:**
* 1 for
21 matches
Mail list logo