@pmatilai commented on this pull request.
> + version = getLibtoolVer(linkmap->l_name);
+ }
+ if (version)
+ (void) write(pipefd[1], version, strlen(version));
+ close(pipefd[1]);
+ free(version);
+ dlclose(dl_handle);
+ _exit(0);
+}
@pmatilai commented on this pull request.
> +destsize = readlink(filename, dest, PATH_MAX);
+if (destsize > 0) {
+ dest[destsize] = 0;
+ filename = dest;
+}
+/*
+ * Start from the end of the string. Verify that it ends with
+ * numbers and dots, preceded by
@gordonmessmer pushed 1 commit.
fccc4383940987f77c78ff4ade5cd692a2c4cbf3 Fallback requirements depend on GNU
extensions.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/957efd320451c2f33cfd704e92b13328683f64e6..fccc4383940987f77c78ff4ade5cd692a2c4cbf3
You
Actual errors (IO and the like) should be fatal, yes. Failing to "parse" a
version out of a weird piece, perhaps not, because there are all sorts of weird
ELF constructs out there.
--
Reply to this email directly or view it on GitHub:
> Also check that I/O errors (`EIO`, `ENOMEM`, `ENOSPC`, `EACCES`, `EPERM`,
> etc) result in a non-zero exit code.
*nod*
I'd asked in a code comment because I wasn't sure of the team's preferences, so
I'll ask it here to be really explicit: Should errors encountered during
fallback version
@gordonmessmer pushed 7 commits.
47db768e45187515dff5561dc5f209661d77b52b Enhance requires with version
information from the build root.
87aa2cbee9537bd6d5bad4fb0f713564a0e40706 Provide macros that can be used to
enable fallback version dependencies.
69c4c345772cfd0228562cc224296ea1cd409213
Also check that I/O errors (`EIO`, `ENOMEM`, `ENOSPC`, `EACCES`, `EPERM`, etc)
result in a non-zero exit code.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1419777020
You are receiving this because you are subscribed
# package after `rpm --delsign` differs from original, unsigned package
## Description
To allow users to reproduce and verify our signed packages locally, we expect
the result of `rpm --delsign package.rpm` to be bit-for-bit identical to the
original unsigned `package.rpm`. This assumption
How i could miss the presence of that option? Then unlike what i wrote,
"_Option missing from RPM(8), 09 June 2002_", it was present. It would be worth
to have an explicit description such as one that takes in account your
statement "_rpm -qp queries a local .rpm file_". Would the following
How i could miss the presence of that option? Then unlike what i wrote,
"_Option missing from RPM(8), 09 June 2002_", it was present. It would be worth
to have an explicit description such as one that takes in account your
statement "_rpm -qp queries a local .rpm file_". Would the following
Note that Max-rpm hasn't been updated in like twenty years. It's interesting as
historical reference, but you don't want to rely on that for documentation.
>From rpm (8):
```
-p, --package PACKAGE_FILE
Query an (uninstalled) package PACKAGE_FILE. The PACKAGE_FILE
@pmatilai commented on this pull request.
> @@ -222,8 +333,17 @@ static void processDynamic(Elf_Scn *scn, GElf_Shdr
> *shdr, elfInfo *ei)
case DT_NEEDED:
if (genRequires(ei)) {
s = elf_strptr(ei->elf, shdr->sh_link, dyn->d_un.d_val);
-
@pmatilai commented on this pull request.
> +if (pipe(pipefd) == -1) {
+ return NULL; // Should this be a fatal error instead?
+}
+cpid = fork();
+if (cpid == -1) {
+ return NULL; // Should this be a fatal error instead?
+}
+if (cpid == 0) {
+ void
rpm -qp queries a local .rpm file, 'dnf repoquery' doesn't download one for you.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2381#issuecomment-1419096159
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2381 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2381#event-8447533161
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
```
$ rpm -q rpm
rpm-4.18.0-1.fc37.x86_64
```
Attestation of availability of a package: with `dnf`
```
$ dnf -q rq --repo=fedora libvirt-client
libvirt-client-0:8.6.0-3.fc37.x86_64
```
Hello. Opening of package failing.
```
$ rpm -vv -qip `dnf -q rq --repo=fedora libvirt-client`
error: open of
@pmatilai commented on this pull request.
> +cpid = fork();
+if (cpid == -1) {
+ return NULL; // Should this be a fatal error instead?
+}
+if (cpid == 0) {
+ void *dl_handle;
+ struct link_map *linkmap;
+ char *version = NULL;
+
+ close(pipefd[0]);
Now I don't have other idea, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2380#issuecomment-1418691309
You are receiving this because you are subscribed to this thread.
Message ID:
Yes, some prefer to keep the builds, but it makes no sense as a default
behavior. The *option* is certainly necessary.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2380#issuecomment-1418679991
You are receiving this because you are
>
Yes, add a recursive chmod is not a good choice. I prefer to not remove build
directory when users don't use `--clean` option.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2380#issuecomment-141867
You are receiving this
We *could* of course add a recursive chmod to the default %clean to ensure it
can be removed, but that seems...
The rpm test-suite is quite a special case and should be treated as such I
think.
--
Reply to this email directly or view it on GitHub:
21 matches
Mail list logo
