Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add support for multiple OpenPGP signatures per package (Issue #3385)
> @Conan-Kudo the simplest policy is that signatures must all verify (why would you put multiple of them otherwise?). > Multiple signatures aren't necessarily for users installing to process, so it would make sense to ignore them in that case. For example, the signatures may be used to indicate something passed through certain stages. You may have a policy to validate them all, but it may not actually be a required policy. Some signatures may only be for some systems to validate but not others. I can think of a variety of reasons for it. But regardless, I think it does make sense to have some way to indicate a primary/key signature to validate. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3385#issuecomment-2460508781 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add support for multiple OpenPGP signatures per package (Issue #3385)
@pmatilai How do we decide when a package "fails" verification with multiple signatures? Would we have a policy tunable? Some kind of indicator as a "primary" signature? Or something else? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3385#issuecomment-2460291327 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add support for multiple OpenPGP signatures per package (Issue #3385)
@JanZerebecki Verifying reproducibility for RPM packages has always required filtering out certain RPM tags. Once those tags are filtered out, it's very easy to identify whether they are reproducible or not. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3385#issuecomment-2451944854 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a new openpgp.cert.d based keystore (Issue #3341)
Yes, more or less. The only other thing I'd like us to do is add the ability to have GPG keys shipped in RPM packages (like `fedora-gpg-keys` does) go into a location in `/usr` rather than `/etc` (e.g. `/usr/lib/sysimage/rpmpgpkeys.d` or similar). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3341#issuecomment-2388104721 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a new openpgp.cert.d based keystore (Issue #3341)
I don't care what the format looks like, but we should not use the same shared PGP certs directory used by plain Sequoia, GnuPG, etc. Essentially, we need to maintain the equivalent of our own keyring with our own import semantics. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3341#issuecomment-2388023040 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a new openpgp.cert.d based keystore (Issue #3341)
Unfortunately, while we can do reasonable things, I can't expect our consumers to. 😓 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3341#issuecomment-2385541522 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a new openpgp.cert.d based keystore (Issue #3341)
> > I'm not so excited about programs shelling out to sq. Although we plan to > > have a stable API in a few months, we still don't have machine-readable > > output. (We plan to implement that in 2025.) I'd rather we specify an API, > > and then I implement it in rpm-sequoia (or some another library?). > > API in rpm-sequoia would be by far preferred by me too, and something I > thought would eventually happen anyhow, this was more based on "what tools do > we have right now". The shell-out part I envisioned would be basically for > import and delete, where the only thing we care is exit code from the call, > not looking at any of the output. Just reading the bits off disk shouldn't be > too complicated for rpm to implement by itself. The overall picture wasn't > probably too clear in the initial description, sorry about that. > I would rather avoid this, because we will wind up in a situation where things parse the output as API. This happened in DNF with rpmkeys and it happens all the time in Zypper too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3341#issuecomment-2382985377 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a new openpgp.cert.d based keystore (Issue #3341)
Honestly, we need our own directories anyway, because we need keys stored in `/usr` preloaded by vendors and keys stored in `/etc` that the user adds. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3341#issuecomment-2382715769 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Drop --pkgid and --hdrid query source cli-switches (PR #3335)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3335#pullrequestreview-2335492068 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format draft, major update (Discussion #2919)
I think defaulting to zstd would be a reasonable choice too. Most distros have been doing this for a while now. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-10779389 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Mass-rename all relevant sources to a C++ extension (Issue #3316)
> > cxx/hxx has the significant benefit that it's the only version with some > > actual, concrete rationale to back it > > Once you put it down this way... it'd seem foolish to do anything else > really. So `.cxx` and `.hxx` it is. Thanks for the input! Note that .hxx for > _C++ only_ headers - so at this point nothing in include/rpm will change. Makes sense to me! Let's do it! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373793947 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Mass-rename all relevant sources to a C++ extension (Issue #3316)
It's somewhat rare these days to have mixed C/C++ headers in a single project, so I can see why they say that. That doesn't mean I agree with it. 😃 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373725339 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Mass-rename all relevant sources to a C++ extension (Issue #3316)
Oh geez, okay whatever, strike that as a reason. 😵 Still, I stand by my original rationale for cxx/hxx. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373713438 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Mass-rename all relevant sources to a C++ extension (Issue #3316)
Also note that C++ modules will use `.ixx`, and if we ever get around to using them for an RPM C++ API interface (in some indeterminate time in the future), it would be nice if everything lined up for it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373665825 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Mass-rename all relevant sources to a C++ extension (Issue #3316)
I'm not a fan of `.cc`/`.hh` simply because it looks like it's associated with the traditional UNIX C compiler binary `cc`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373660009 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Mass-rename all relevant sources to a C++ extension (Issue #3316)
You can also use `.c++`/`.h++` if you're feeling bold... 😛 All the valid extension types are listed [on the Wikipedia page for the language](https://en.wikipedia.org/wiki/C%2B%2B). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373610929 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Mass-rename all relevant sources to a C++ extension (Issue #3316)
CMake itself uses it, and when I first learned C++, I used it for my stuff too. 😅 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373607449 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add switches to rpmspec for accessing sources and patches (Issue #3315)
I don't see why we couldn't do download, it's the main use-case of rpmdev-spectool, and I would actually prefer it to be part of rpmspec, since that would resolve the issue with specs with NoSource sources. And eventually we do want to tackle #463 too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3315#issuecomment-2371136315 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Mass-rename all relevant sources to a C++ extension (Issue #3316)
I'm fine with `.cxx`/`.hxx` or `.cpp`/`.hpp`. I have a slight preference for `.cxx`/`.hxx` simply because it disambiguates with the C preprocessor and it also lines up with the usage of `CXXFLAGS` as the environment variable for C++ compiler flags. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2371122728 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate/convert manual pthread synchronization with STL counterparts (PR #3302)
@Conan-Kudo commented on this pull request.
> +struct tagTable {
+private:
+headerTagTableEntry byName[TABLESIZE]; /*!< tags sorted by name */
+headerTagTableEntry byValue[TABLESIZE]; /*!< tags sorted by value */
-/* Initialize tag by-value and by-name lookup tables */
-static void loadTags(void)
+public:
+tagTable();
+headerTagTableEntry getEntry(const char *tag);
+headerTagTableEntry getEntry(rpmTagVal tag);
+int getNames(rpmtd tagnames, int fullname);
+};
Also, with rolling over to a new major, we can change the C API that we expose
somewhat too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3302#discussion_r1771297999
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate/convert manual pthread synchronization with STL counterparts (PR #3302)
@Conan-Kudo commented on this pull request.
> +struct tagTable {
+private:
+headerTagTableEntry byName[TABLESIZE]; /*!< tags sorted by name */
+headerTagTableEntry byValue[TABLESIZE]; /*!< tags sorted by value */
-/* Initialize tag by-value and by-name lookup tables */
-static void loadTags(void)
+public:
+tagTable();
+headerTagTableEntry getEntry(const char *tag);
+headerTagTableEntry getEntry(rpmTagVal tag);
+int getNames(rpmtd tagnames, int fullname);
+};
But we _could_ convert those to classes, and have struct aliases for the legacy
data-only modeling for the C API, no?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3302#discussion_r1771295137
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate/convert manual pthread synchronization with STL counterparts (PR #3302)
@Conan-Kudo commented on this pull request.
> +struct tagTable {
+private:
+headerTagTableEntry byName[TABLESIZE]; /*!< tags sorted by name */
+headerTagTableEntry byValue[TABLESIZE]; /*!< tags sorted by value */
-/* Initialize tag by-value and by-name lookup tables */
-static void loadTags(void)
+public:
+tagTable();
+headerTagTableEntry getEntry(const char *tag);
+headerTagTableEntry getEntry(rpmTagVal tag);
+int getNames(rpmtd tagnames, int fullname);
+};
I guess for me, I see `struct` as a way to do C-style data-only layouts. As
soon as you add methods to the thing, I would expect it to be a `class`.
I am aware that classes are basically fancy structs with extra sugar, but the
way I (and I think most people) expect to look at a C++ codebase is that
`struct` is data-only while `class` can have data + methods.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3302#discussion_r1771232836
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate/convert manual pthread synchronization with STL counterparts (PR #3302)
@Conan-Kudo commented on this pull request.
> +struct tagTable {
+private:
+headerTagTableEntry byName[TABLESIZE]; /*!< tags sorted by name */
+headerTagTableEntry byValue[TABLESIZE]; /*!< tags sorted by value */
-/* Initialize tag by-value and by-name lookup tables */
-static void loadTags(void)
+public:
+tagTable();
+headerTagTableEntry getEntry(const char *tag);
+headerTagTableEntry getEntry(rpmTagVal tag);
+int getNames(rpmtd tagnames, int fullname);
+};
Can we just use `class` then? Because it's a little weird to see `struct` used
this way.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3302#discussion_r1771213536
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enable C++ exceptions on the codebase (PR #3325)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3325#pullrequestreview-2321870760 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate/convert manual pthread synchronization with STL counterparts (PR #3302)
@Conan-Kudo requested changes on this pull request.
> +struct tagTable {
+private:
+headerTagTableEntry byName[TABLESIZE]; /*!< tags sorted by name */
+headerTagTableEntry byValue[TABLESIZE]; /*!< tags sorted by value */
-/* Initialize tag by-value and by-name lookup tables */
-static void loadTags(void)
+public:
+tagTable();
+headerTagTableEntry getEntry(const char *tag);
+headerTagTableEntry getEntry(rpmTagVal tag);
+int getNames(rpmtd tagnames, int fullname);
+};
How does this work? I didn't think `struct` supported
`private`/`protected`/`public`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3302#pullrequestreview-2316379909
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document rpm design philosophy in the manual (Issue #2897)
There are package management extensions at higher layers that should probably be considered to incorporate into this for stuff like EULAs... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2897#issuecomment-2327717275 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Build version (build tag?) in RPM (Discussion #2031)
I think another part missing from this thread is that the build system "burns in" the value of Release into the spec file before running rpmbuild, so it's part of the shipped artifact. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2031#discussioncomment-10538845 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
As I think about this, I come back to my long-ago closed ticket #362. Fundamentally, we need stronger symbol dependencies represented somehow, and we need it in a way that we don't bind things to specific implementations so that switching is still workable. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2327654990 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make Buildsystem %conf section optional (PR #3245)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3245#pullrequestreview-2249162407 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor ordering code to use STL containers (PR #3243)
@Conan-Kudo approved this pull request. Wow, this is quite the cleanup! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3243#pullrequestreview-2249161023 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: watermark short-circuit'ed binaries (Issue #3091)
> Mock guarantees the "production readiness" and "reproducibility" of the > result. Running the final -ba without noprep would gain no benefit to mock. No, it does not. Mock just runs dnf and rpmbuild in repeating sequences. That doesn't guarantee any reproducibility. What guarantees reproducibility is a stable build environment definition. For Fedora, Koji provides that. Other distributions use their own infra (OpenMandriva's ABF, as an example) to do that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2264975057 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Minimally bring back --buildroot and %{_buildrootdir} (PR #3139)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3139#pullrequestreview-2093808138 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] --build-in-place multiple flaws (Issue #3131)
I think there'd be interest in having this wired up in mock if it was easier to use... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2141048489 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: watermark short-circuit'ed binaries (Issue #3091)
Note that Yocto already guts our poison logic from short-circuit builds, since the entire distribution is built short-circuited. https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2137082520 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Always create %specpartsdir on build (PR #3084)
This should still get it created in `%prep`, right? It _seems_ like that's the case. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3084#issuecomment-2106394010 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Always create %specpartsdir on build (PR #3084)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3084#pullrequestreview-2051465619 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add proper logic for debuginfo enablement (PR #3085)
@Conan-Kudo approved this pull request. This is a lot cleaner and I like this setup. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#pullrequestreview-2051465542 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Dynamic spec generation depends on %setup (for no good reason) (Issue #3063)
So this is similar to #3042 (and probably really just a more generic version of that issue). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3063#issuecomment-2092561549 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Drop architecture from %builddir path (PR #3069)
Oh hey, thanks for that! 😅 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3069#issuecomment-2089251801 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
So what does this do when we use it to declare only a subpackage as noarch? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2085451141 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert a bunch of librpmio stuff to native C++ (PR #3054)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3054#pullrequestreview-2015563636 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)
Yeah, I've always been afraid of broaching the idea seriously. I had joked about this with @ffesti a few times at the openSUSE Conference, but I'm really glad to see us doing this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8982957 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add --patches and --sources aliases to rpmspec (PR #3011)
@Conan-Kudo requested changes on this pull request. Actually, since these emit the sources and patches in reverse order, could we make the aliases also reverse that so they are in the correct order? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3011#pullrequestreview-1973492350 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make it possible to evaluate arbitrary macros in the context of a given spec file (Discussion #3008)
Could you fix it for your rpmspec aliases though? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8982821 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add --patches and --sources aliases to rpmspec (PR #3011)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3011#pullrequestreview-1973096004 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for bare `%package` (Discussion #2959)
So is the idea to be able to mimic the `debian/control` style of the top preamble actually being for the source package only, and then a bare `%package` section for the binary package of the same name? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8974431 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a way to ensure build artifacts integrity after the `%build`, and during post-build phases like `%check` (Discussion #3009)
Yeah, it would be interesting for sure. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3009#discussioncomment-8974419 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)
For what it's worth, I'm excited about the transition to C++, because as a C++ programmer, I feel much more comfortable working my way through and cleaning things up leveraging the things I know well. So I'm looking forward to this! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8953488 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make it possible to evaluate arbitrary macros in the context of a given spec file (Discussion #3008)
This would be tremendously useful, especially for me trying to dig through really complex packages... Some of them are just not able to be intuited by reading, and being able to probe them like this would be really useful! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8945747 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support per-user macro configuration in XDG_CONFIG_HOME (PR #2992)
@Conan-Kudo requested changes on this pull request.
> +#ifdef MACROFILES
+static char *initMacroPath(const char *confdir)
+{
+return xstrdup(MACROFILES);
+}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initMacroPath(const char *confdir)
+{
+const char *xdgconf = getenv("XDG_CONFIG_HOME");
+if (!(xdgconf && *xdgconf))
+ xdgconf = "~/.config";
+char *dotpath = rpmGetPath(xdgconf, "/rpmmacros", NULL);
What about `$XDG_CONFIG_HOME/rpm/macros` instead? That mimics what we do in
`/etc/rpm` too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#pullrequestreview-1958109674
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for setting the build time and clamping to the build time (PR #2944)
@Conan-Kudo commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+# are not later than the build time of the package.
+%clamp_mtime_to_buildtime 0
I will preface this that I think adding this knob is a seriously bad idea. But,
I think @pmatilai is right that _if_ we're going to do this, we should change
to a mode-setting macro like `%clamp_mtime` and have mode options.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#discussion_r1528334316
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
@Conan-Kudo commented on this pull request.
> - goto exit;
- }
- if (rstreq(buildRoot, "/")) {
- rpmlog(RPMLOG_ERR, _("%%{buildroot} can not be \"/\"\n"));
- goto exit;
+ if (!spec->buildDir) {
+ /* Grab top builddir on first entry as we'll override _builddir */
+ if (!rpmMacroIsDefined(spec->macros, "_top_builddir")) {
+ char *top_builddir = rpmExpand("%{_builddir}", NULL);
+ rpmPushMacroFlags(spec->macros, "_top_builddir", NULL,
+ top_builddir, RMIL_GLOBAL, RPMMACRO_LITERAL);
+ free(top_builddir);
+ }
+
+ /* Using release here causes a buildid no-recompute test to fail */
+ spec->buildDir =
rpmExpand("%{_top_builddir}/%{NAME}-%{VERSION}-%{_arch}", NULL);
Can we please not include architecture? That can leak into builds and cause
problems. That's why I had to make an adjustment in redhat-rpm-config for
`%_vpath_builddir`:
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/e0cfcc0fc76a7642faabb25c5e348d6a1314ace2
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#pullrequestreview-1936534049
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format draft, major update (Discussion #2919)
I'd probably go with `RPMTAG_FILEMIME`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8757616 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: multi-arch dependencies (Issue #2197)
> soft FP is a very rare thing these days, that's the exception that should be > encoded if at all - I know it's a thing you need to care about on Arm, at > least in the past, but is it something that needs to be in every single > dependency, really? We may need to care about it again with RISC-V. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2197#issuecomment-1985537895 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
For a path, maybe this is where we finally introduce `/usr/lib/sysimage` as an expected path. I could see something like `/usr/lib/sysimage/rpm-config` be a valid location to store a whole hierarchy of pristine config files. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1178#issuecomment-1985520373 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] CMakeLists.txt: eliminate floating dependencies (PR #2914)
@Conan-Kudo approved this pull request. Sure, I suppose. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2914#pullrequestreview-1916977215 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#pullrequestreview-1911698628 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
Sounds good to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973616134 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
Oh, wouldn't we need these fixups for all the VCS backends, not just Git? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973534254 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I don't think it's a good idea to offer. I am not convinced these knobs are a good idea for RPM to expose for any reason, especially reproducibility. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643933 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I am aware of some tools that use `RPMTAG_BUILDTIME` to sort packages in various situations, especially if they have the same NVRA (ie. rebuilds). It is also useful in diagnostic purposes when trying to figure out a factor of breakage. I would rather not falsify this tag. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643922 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
> Before commit > https://github.com/rpm-software-management/rpm/commit/b34333fa021c0ee7215714eeef96d1a2843ea08e, > rpmbuild has by default kept built artifacts. RPM has deleted the buildroot tree by default since RPM 4.6. If it wasn't doing that before, that's a bug. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643193 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I've been bitten enough times personally that I would rather not have BUILDHOST and BUILDTIME set to fake values. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8630113 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
You already need all the inputs to correctly reproduce packages in openSUSE. The build system doesn't capture this, but it's still required. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8618519 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
It's also important to keep in mind the context of Debian style reproducibility: their archive format is a tarball with ar archives inside. That makes things very different for them than us. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8617949 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
Locking down the stored build time in the rpm headers to `SOURCE_DATE_EPOCH` can have other undesirable side-effects, so generally I wouldn't want that to be a thing for Fedora or any distribution, really. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1967579370 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2933#pullrequestreview-1903336269 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
If we're not clamping the build-time but want the commits to be clamped (which is Fedora's configuration), then this is the way we need to do it. I do think that if SOURCE_DATE_EPOCH isn't set, we should clamp to RPM_BUILD_TIME though. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1966414614 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
I don't think bumping the changelog for rebuilds is actually important, but I do think that this is still the wrong way to solve it, because we're presuming that _a rebuild is important_. When rebuilds happen every day for whatever reason due to dependency churn, they are no longer important. But that doesn't change anything about handling `$SOURCE_DATE_EPOCH`, because the presumption is that the date doesn't matter because you're fixing it to a fake time anyway. So this is solving the wrong problem anyway. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1966407685 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
Since I was tagged in here and for some reason people think I don't care about reproducibility, let me be clear, I do care about it. However, neither Fedora nor openSUSE suffer from the problems Debian has that necessitated reproducible builds, and the nature of the RPM format vs the Debian format means that we do not have the same problems they do with build data influencing the payload reproducibility. Fedora has been so far ahead of Debian on this and the Koji build system provides guarantees (at the consequence of trade-offs like increased disk usage over time) that neither Debian's system nor OBS provide that there is less urgency around the issue. In general, rebuilds should not mutate or influence how reproducible builds behave. I'm confused by the problem you're saying you have: build-compare shouldn't have an issue with SOURCE_DATE_EPOCH being clamped to the changelog, since that's unchanging. The only issue I know if is that if you clamp the buildtime and don't change the Release, you wind up in a situation where it becomes difficult to sort for the newer package. Since OBS changes the Release for every rebuild, this isn't strictly an issue, but openSUSE should not be clamping the buildtime regardless. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1956556571 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Issue #2894)
Clamping the mtime to buildtime has its own negative consequence too, because it makes it harder to reason reproducibility and it invalidates reproducibility in practice because every build will be different due to a variable clamp rather than an immutable clamp. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956534803 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Issue #2894)
One of the reasons for the knobs is that not all of these settings are fully useful for "reproducibility" and some of these harm traceability and debugging. For example, forcing the build host to `reproducible` does not provide much value if you are able to do comparisons while stripping/ignoring specific RPM header values and makes it harder to determine when something weird is happening as a result of a build host in real-world debugging efforts. This is similarly true for clamping build times, and has the negative consequence of making it difficult for tools to sort packages when they were built with the same NVR. Setting `SOURCE_DATE_EPOCH` from the changelog provides value because it influences how the build itself records timestamps. Clamping mtimes provides value because it eliminates variability from the payload. Everything we do around "reproducible builds" needs to be viewed with the lens of handling this balance. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956531794 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format draft, major update (Discussion #2919)
> proper multiarch dependencies (instead of ()(64bit) markers) As a reminder, I took a stab at this in #360 and later #1038. The big change since then is the introduction of subarches for both ARM and x86_64, and I still expect that to happen for RISC-V too. What are we thinking for this now? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8529506 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] CMakeLists.txt: eliminate floating dependencies (PR #2914)
We didn't even do this with the Autotools build scripts, I don't think we should make it so strict in the CMake build script either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1954138148 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Including a file, expanding the macros in it and writing the result to another file? (Discussion #2912)
This should do the trick: ``` cat > expanded
Re: [Rpm-maint] [rpm-software-management/rpm] Adjust User/Group handling Documentation (PR #2903)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2903#pullrequestreview-1879061365 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
FYI: @davide125 @michel-slm -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1918382019 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
I will also point out that this is premised on some kind of "build counter" property that we don't have. @bookwar proposed [adding something like this to RPM and extending NVR to NVRB some time ago](https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms-nvr-nvrb/39954), but there has been no movement on that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1918381531 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
This seems to defeat the point. The point of this is to clamp the times to the date stamp in the changelog. If you're doing automatic rebuilds, you should not use that feature, full stop. You've effectively created a situation where your builds are not reproducible outside of your build system with the build system circumstances that created it. >From my reading of this, this is a very bad idea, and I'm not sure we should >have this. I also think that if this is something openSUSE is going to ship, >it should stop saying it's doing reproducible builds. (Yes, I'm aware of all the caveats of reproducible builds, please don't add more of them!) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1918379446 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)
@Conan-Kudo approved this pull request. Modulo note as @dmnks stated, it looks good to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#pullrequestreview-1833116074 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] add build directory auto path to setup step (PR #2859)
@Conan-Kudo requested changes on this pull request.
> @@ -17,6 +17,7 @@ target_link_libraries(rpmlua PRIVATE LUA::LUA)
target_link_libraries(rpmbuild PRIVATE librpmbuild)
target_link_libraries(rpmspec PRIVATE librpmbuild)
target_link_libraries(rpmdeps PRIVATE librpmbuild)
+target_link_libraries(rpmuncompress PRIVATE archive)
Is this the name of the dependency? It looks like it's `LIBARCHIVE` instead of
`archive`.
> @@ -509,6 +509,9 @@ can just create the directory. It accepts a number of
> options:
-n DIR set the name of build directory (default is `%{name}-%{version}`)
-T skip the default unpacking of the first source (used with
`-a` or `-b`)
+-p ensures that the sources will be in the default build directory,
How would this be exposed in `%autosetup`? We can't use `-p` there since that's
for patchlevel passed to `patch`. Maybe instead use `-C` and describe it as
`Create the build directory and ensure the archive contents are unpacked there,
stripping the top level directory in the archive if it exists`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2859#pullrequestreview-1832404055
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#pullrequestreview-1821554619 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
Thanks for finally landing this! 🚀 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1892038147 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1815228582 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
@Conan-Kudo commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. Unless someone is committing to doing that same work in Discussions, we should not be telling people to go there. Discussions should not be treated like that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1444584514 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
@Conan-Kudo commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. I don't think that's necessary, since Issues can be converted into Discussions and back. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1443692028 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
Group tag is still used by the Mandrake family (Mageia, OpenMandriva, PLD, ALT, etc.). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8024703 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Make `%setup` work with archives regardless of inner structure (Issue #2664)
Not quite. If it contains a single entry, strip it. Always create the directory `%name-%version` and extract into it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1877539519 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Make `%setup` work with archives regardless of inner structure (Issue #2664)
Yup. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1877538632 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Make `%setup` work with archives regardless of inner structure (Issue #2664)
I believe we have to inspect it to check. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1877526112 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Make `%setup` work with archives regardless of inner structure (Issue #2664)
> Note that because of compatibility concerns, we'd probably want this new > behavior in a new macro. We could make `%autosetup` use this behavior by default when `-n` isn't present, though. It's a "do-what-I-mean" change that would be beneficial for most. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1874359095 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: Deduplicate data among binary packages produced by the same source package in the rpmdb (Issue #2827)
With more and more packages, especially in the distributions that do library subpackaging by soname (such as openSUSE, Mageia, and OpenMandriva), there's a lot of data that comes from the source package that has duplicate entries in the rpmdb per binary package. The largest offender of this is the changelog data, but sometimes also license tags and a few other things wind up being the same. A nice optimization for this would be to have a skeleton "source package" rpmdb entry with that data and put the common data there and have the binary package entries in the rpmdb link to that. This can lead to significant shrinkage of the rpmdb depending on distro policy on packaging. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2827 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
But you shipped it and then unshipped it, so now you can't even do mock or chroot builds of those releases. If handling stuff like this is properly fixed in RPM, there's no reason to not have some way to emit those `rpmlib()` capabilities either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1851936907 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
If we can solve this somehow, can we also bring in the old `rpmlib()` things from [this patch](https://src.fedoraproject.org/rpms/rpm/blob/f20/f/rpm-4.10.90-rpmlib-filesystem-check.patch) so that dnf installroot installs for affected distributions don't fail like this? ``` Running transaction check Error: transaction check vs depsolve: rpmlib(X-CheckUnifiedSystemdir) is needed by setup-2.8.48-1.fc17.noarch rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.x86_64 To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'. You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue. ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1830850932 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@Conan-Kudo requested changes on this pull request. > +%buildsystem_python_build +``` + +## Supporting new build systems + +Supporting new build system types is just a matter of declaring a few +macros for the build scriptlet sections relevant to the build system. + +Scriptlet | Mandatory | Buildsystem macro +--- +`%prep` | No| `%buildsystem_name_prep` +`%conf` | Yes | `%buildsystem_name_conf` +`%generate_buildrequires` | No| `%buildsystem_name_generate_buildrequires` +`%build` | Yes | `%buildsystem_name_build` +`%install`| Yes | `%buildsystem_name_install` +`%check` | No| `%buildsystem_name_install` ```suggestion `%check` | No| `%buildsystem_name_check` ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1744225951 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: file triggers v2 (Issue #2655)
We should support all the same features for a file list entry here, which also means being able to handle regular expressions. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2655#issuecomment-1798345651 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a declarative autobuild system (prototype) (PR #2620)
`BuildSystem`, `BuildType`, and `BuildOption(stage)` makes sense to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794452101 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: introduce an rpm-controlled per-build directory to builds (Issue #2078)
Couldn't we just make `%setup -c` the default behavior and then strip the top level directory automatically when extracting an archive? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2078#issuecomment-1792049118 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Disallow most control characters in at least %summary, %description and %changelog (Issue #2742)
I thought we already disallowed these at some point? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2742#issuecomment-1792046552 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set %_sharedstatedir to %{_var}/lib (PR #2743)
@Conan-Kudo approved this pull request. I do this in `debbuild`, I didn't realize we never fixed it in RPM. 😅 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2743#pullrequestreview-1712040562 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
