@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
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
@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
@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
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
@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.
> +
+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.
> +
+ 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 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:
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
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 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,
@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
@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,
@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
(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:
@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:
@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
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:
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.
21 matches
Mail list logo
