Yup, too busy, mostly with a certain security issue.
I've actually picked this up again just last week (but left for a conference on
Thursday). It's now on the top of my TODO list :)
--
Reply to this email directly or view it on GitHub:
@dmnks pushed 1 commit.
eed84b1cc17eeb2bcb8bdcf9471bd0f056240b02 Fix tagtbl.C placement in build dir
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2670/files/87825c0232803f7040ed3c7e4c60e54dc8500603..eed84b1cc17eeb2bcb8bdcf9471bd0f056240b02
You are receiving this
thank you very much! I'll follow the new issue
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2617#issuecomment-1722851929
You are receiving this because you are subscribed to this thread.
Message ID:
The COMMAND for tagtbl.C generation dumps the file in the top-level build
directory whereas the OUTPUT is specified in the current (lib/) directory.
This leads to unnecessary relinking of all the libraries on each make
invocation because OUTPUT is always missing.
Fix this by outputting the
Let's talk about a major security issue which I think is very important, yet is
not currently solved in any shape or form.
RPM packages can be signed, and Fedora and RHEL packages are.
The issue however is neither Fedora, nor RHEL keeps intermediate update
packages on the server, so it's quite
The container environment is reused for each step in a "job", but each job is
separate.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2667#issuecomment-1724681265
You are receiving this because you are subscribed to this thread.
> The issue however is neither Fedora, nor RHEL keeps intermediate update
> packages on the server, so it's quite a common configuration to have packages
> are installed where the source Fedora/RHEL packages cannot be downloaded or
> found anywhere on the Internet since they have been
