@pmatilai Personally, I'd also like a solution to an annoying case that I have
on macOS where I have binaries with multiple architectures in them. What you're
saying here could probably be expanded to handle that too, I suppose, since it
essentially turns architectures into qualifiers for files/
I'm not sure we can do that, because the point of this handler is to ensure the
rpmdb is sane in those scenarios.
--
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/pull/1667#issue
So I guess then, the question would be to @mlschroe if NDB still needs this?
--
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/pull/1667#issuecomment-848991740_
If you're going to do this, wouldn't it just make more sense to just use
`%patch` instead?
--
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/pull/1673#issuecomment-851062160__
@vorot93 It was definitely in poor taste, and given our experience with the
LMDB upstream, we're pretty wary of having an upstream who wouldn't be
responsive to the larger community of RPM users that would consume MDBX. We
were burned once, and we don't want to be burned again. If someone wants
> Anyway, you say you were "burned by upstream". Was it LMDB's upstream?
> Because if so, this is squarely one of the reasons why we switched to MDBX.
Yes. We were burned by attitude and broken promises from the LMDB developer.
--
You are receiving this because you are subscribed to this thread
@Conan-Kudo approved this pull request.
--
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/pull/1667#pullrequestreview-682454021___
R
Considering MDBX is forked from LMDB, I don't think that's exactly true in this
case.
--
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/958#issuecomment-860589901__
In this case, I actually _disagree_ with @pmatilai because I think RPM moves
too slowly as it is, and we can easily accept another backend and have it in
experimental status, like we did for NDB (which is now stable after some
real-world testing).
--
You are receiving this because you are subs
> I'm concerned that re-implementing parts of rpm has the potential to double
> the surface area for bugs. I get that writing code in C is more difficult and
> error prone than other languages.
This has generally been borne out to be true, so I generally will advocate for
people to _not_ take t
There should also be a requirement that commits have detailed information in
them. PRs are ephemeral, commits are forever.
(RPM itself has changed VCSes twice, so the commit information is all we
have...)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@Conan-Kudo approved this pull request.
--
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/pull/1709#pullrequestreview-698127175___
R
@Conan-Kudo approved this pull request.
🤦🏾♂️
--
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/pull/1743#pullrequestreview-698127720___
@Conan-Kudo approved this pull request.
I don't think it's a problem to merge this, we clearly intended to raise the
Lua version accordingly when we gutted all the backwards compat code and
reworked it for Lua 5.4 support.
--
You are receiving this because you are subscribed to this thread.
@Conan-Kudo approved this pull request.
--
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/pull/1709#pullrequestreview-701807264___
R
@Conan-Kudo commented on this pull request.
> @@ -13,5 +13,5 @@ Darwin*) exit 0 ;;
esac
# Strip ELF binaries
-find "$RPM_BUILD_ROOT" -type f \! -regex "${RPM_BUILD_ROOT}/*usr/lib/debug.*"
-print0 | \
+find "$RPM_BUILD_ROOT" -type f \! -regex "${RPM_BUILD_ROOT}/*usr/lib/debug.*"
\! -name "*
@Conan-Kudo commented on this pull request.
> @@ -13,5 +13,5 @@ Darwin*) exit 0 ;;
esac
# Strip ELF binaries
-find "$RPM_BUILD_ROOT" -type f \! -regex "${RPM_BUILD_ROOT}/*usr/lib/debug.*"
-print0 | \
+find "$RPM_BUILD_ROOT" -type f \! -regex "${RPM_BUILD_ROOT}/*usr/lib/debug.*"
\! -name "*
> Github is trusted because of in git (i.e. block-chain) it's impossible to
> have different content under the same hash-tag.
That's not actually true. Git uses SHA1 and collisions have been done to Git
with it. That also said, GitHub archives may or may not be reproducible. And
Git refs are no
@Conan-Kudo approved this pull request.
--
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/pull/1757#pullrequestreview-734613454___
R
It'd be nice to have this in RPM 4.17.0 anyway, so that this wouldn't come up
again...
--
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/pull/1757#issuecomment-902382865__
> An actual real world use case:
>
> * EL 8.3 has `hwloc-1.x`
> * EL 8.4 has `hwloc-2.x`
>
> They are ABI incompatible. EL 8.4 also has `compat-hwloc1` which is ABI
> compatible with `hwloc-1.x`, allowing software developed on EL 8.3 to work on
> 8.4.
>
> But this also means that any software
> My being able to build hwloc2 with an Obsoleted-by: hwloc > 1 would achieve
> this.
No. It doesn't matter. Your package doesn't even depend on `hwloc1` but rather
`libhwloc.so.5()(64bit)`. What you want is the development headers associated
with that library to still be available.
> And this
@Conan-Kudo approved this pull request.
--
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/pull/1773#pullrequestreview-751913126___
R
@Conan-Kudo approved this pull request.
--
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/pull/1776#pullrequestreview-756419473___
R
@Conan-Kudo approved this pull request.
--
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/pull/1778#pullrequestreview-776065643___
R
@Conan-Kudo requested changes on this pull request.
> +Format: 1.0-rpm
+Build-Architecture: $(uname -m)
+Source: $RPM_PACKAGE_NAME
+Epoch: $RPM_PACKAGE_EPOCH
+Version: ${RPM_PACKAGE_VERSION}
+Release: ${RPM_PACKAGE_RELEASE}
+Architecture: $RPM_ARCH
+Build-Origin: $(getos)
+Build-Path: $RPM_BUILD
@Conan-Kudo commented on this pull request.
> +
+mkdir -p "$BUILDINFO_DIR"
+
+cat > "$BUILDINFO" <> "$BUILDINFO"
And I'd rather not have Debian-isms in here.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.
@Conan-Kudo commented on this pull request.
> +Format: 1.0-rpm
+Build-Architecture: $(uname -m)
+Source: $RPM_PACKAGE_NAME
+Epoch: $RPM_PACKAGE_EPOCH
+Version: ${RPM_PACKAGE_VERSION}
+Release: ${RPM_PACKAGE_RELEASE}
+Architecture: $RPM_ARCH
+Build-Origin: $(getos)
+Build-Path: $RPM_BUILD_DIR
Al
Koji has a similar build environment record, though it's stored in the Koji
database rather than as a file. We do archive environment artifacts from Mock
with builds too, though.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitH
@Conan-Kudo commented on this pull request.
> +
+printf 'Installed-Build-Depends:\n' >> "$BUILDINFO"
+rpm -qa --queryformat '%{epoch}:%{name}-%{version}-%{release}.%{arch}\n' \
+| LC_ALL=C sort -t: -k2 \
+| sed -e 's/^(none)://; /\.(none)$/d; s/^/ /' >> "$BUILDINFO"
+
+printf 'Environmen
@Conan-Kudo commented on this pull request.
> +
+mkdir -p "$BUILDINFO_DIR"
+
+cat > "$BUILDINFO" <> "$BUILDINFO"
I'm fine with another filename.
--
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-softw
@Conan-Kudo approved this pull request.
--
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/pull/1797#pullrequestreview-790035854___
R
We can probably do this with the CMake build and rip out everything else.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/130#issuecomment-1282247535
You are receiving this because you are subscribed to this thread.
Message ID:
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2231#pullrequestreview-1145684435
You are receiving this because you are subscribed to this thread.
Message ID: __
We probably should mark the autotools build as deprecated now and prioritize
recommending the cmake build...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2231#issuecomment-1282297343
You are receiving this because you are subscribed to
Yay!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2238#issuecomment-1287991040
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-mai
@pmatilai You can use CPack for this, I believe?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/commit/61bb33e593c0fa56aaca935da2007fe9bb848fd2#commitcomment-87617945
You are receiving this because you are subscribed to this thread.
Message I
> Thoughts? Downsides I'm not seeing? Multiple different versions of a provide
> is not something we commonly have so there may be gremlins related to that.
Actually, why don't we do this for adding the actual version for soname
dependencies? I don't think it makes sense to use the arch this way
I mean something like this: `libfoo.so.1 = 1.2.3`. Debian actually does this in
their symbol files, which allows packages to determine what minimum version
alongside a soname they need.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2
@frozencemetery Can you change `Also-authored-by` to `Co-authored-by`? The
latter is the generally recognized "magic tag" by Git commit processing
automation.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2249#issuecomment-1318604927
Y
> Yes it happens a lot, in one highly specific corner. Which is often best
> served by having that specific corner handle it because it has its own
> wrinkles that do not apply elsewhere, like version comparing the name here.
>
> In principle, Debian versioning isn't _that_ different from rpm. I
@Conan-Kudo commented on this pull request.
> +# in this Software without prior written authorization of the copyright
> holder.
+#
+
+set -e -o pipefail
+
+getos() {
+# shellcheck disable=SC1091
+test -r /etc/os-release && . /etc/os-release
+if test -z "${ID}"; then
+ID="$(
@Conan-Kudo commented on this pull request.
> +# in this Software without prior written authorization of the copyright
> holder.
+#
+
+set -e -o pipefail
+
+getos() {
+# shellcheck disable=SC1091
+test -r /etc/os-release && . /etc/os-release
+if test -z "${ID}"; then
+ID="$(
@Conan-Kudo commented on this pull request.
> +
+printf '%s' "\
+Format: 1.0
+BuildArchitecture: ${RPM_BUILD_ARCH}
+Name: ${RPM_PACKAGE_NAME}
+Epoch: ${RPM_PACKAGE_EPOCH}
+Version: ${RPM_PACKAGE_VERSION}
+Release: ${RPM_PACKAGE_RELEASE}
+Architecture: ${RPM_ARCH}
+BuildOS: ${RPM_BUILD_OS}
+Build
@Conan-Kudo commented on this pull request.
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY
> RIGHTS. IN
+# NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
+# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+# OTHERWISE, AR
@Conan-Kudo commented on this pull request.
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY
> RIGHTS. IN
+# NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
+# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+# OTHERWISE, AR
This is by design, as RPM Lua is not _exactly_ a pristine Lua environment and
some stuff would conflict with what RPM Lua provides.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332164363
You are receiving this beca
We have custom RPM Lua API extensions in the interpreter environment, and
custom versions of some modules integrated as well. If this worked before, that
was almost certainly a mistake and it shouldn't.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manage
Also RPM Lua can be used for scriptlets at install-time, and we have no safe
way to handle dependencies for that right now (@michel-slm is working on Lua
module packaging and dependency generators, which may allow us to revisit that
eventually).
--
Reply to this email directly or view it on Gi
Crashing the RPM process and potentially bricking someone's installation is not
acceptable, and that's what would happen if someone screwed up this without
safeguards in place.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2309#issue
@hramrach the RPM Lua environment is an in-process interpreter. If it breaks in
an unrecoverable way, librpm dies, which kills the whole transaction. It was
never intended to be extensible at runtime for this reason.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-s
This cannot be dropped, subkeys are used by a number of prominent users
(including AlmaLinux). Dropping this will make it difficult for various build
environments to use RPM to verify signatures.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rp
I know @dmach was working on [libarch](https://github.com/dmach/libarch) to
deal with this problem (of centralizing and simplifying arch detection code).
Maybe he's interested in reviving this so we can deal with this and #1035.
Because I still want to get this problem sorted out. 😩
--
Reply
@Conan-Kudo commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64 p
@Conan-Kudo commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64 p
To the best of my knowledge, hwcaps are _not supported_ by musl-libc
(@richfelker, can you confirm?) and other non-glibc platforms that RPM is
commonly used on.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2318#issuecomment-1344250
I think it'd be worth looking at @dmach/@ffesti's
[libparch](https://github.com/rpm-software-management/libparch) to get us a
consistent way to handle all this. Then everything in the ecosystem can rely on
a single mechanism (libsolv, librpm, libdnf, etc.).
--
Reply to this email directly or v
I think it'd be worth looking at @dmach / @ffesti's
[libparch](https://github.com/rpm-software-management/libparch) to get us a
consistent way to handle all this. Then everything in the ecosystem can rely on
a single mechanism (libsolv, librpm, libdnf, etc.).
--
Reply to this email directly or
@Conan-Kudo commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64 p
I used 3.12 for popt because that's the minimum version with helper functions
for easily creating the cmake config/version files for `find_package()`. I'm
fine with this as the minimum for rpm too.
(I was going to bump it anyway when I synced my improvements from popt into rpm
😅 )
--
Reply to
@Conan-Kudo approved this pull request.
🤦🏾
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2337#pullrequestreview-1239928285
You are receiving this because you are subscribed to this thread.
Message ID: ___
We're not using FindLibLZMA in here, though. We use `pkg_check_modules()` and
made the variable `LIBLZMA`, so that's why it's `LIBLZMA` and not `LibLZMA`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2337#issuecomment-1375477867
You ar
Yup!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2337#issuecomment-1375485154
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-mai
@Conan-Kudo approved this pull request.
Blech. Fine...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2341#pullrequestreview-1240587251
You are receiving this because you are subscribed to this thread.
Message ID:
In general, this seems interesting to me, though I'm curious about the caveats.
(I also generally wonder why this isn't just being introduced as a Python 4 so
we can switch Python to major versioned directories instead of major+minor
versioned directories...)
--
Reply to this email directly or
> Right something writes it into ~/.rpmmacros . That is our problem then and
> the `-j%{_RPM_BUILD_NCPUS} ` rpm patch should still be good.
This is probably `obs-build`, which redefines a bunch of stuff in
`~/.rpmmacros` when it shouldn't.
--
Reply to this email directly or view it on GitHub:
>From my perspective, the minimum *I* care about is Python 3.9, since that's
>the RHEL 9 minimum. I would _like_ to have Python 3.6 if we can work it to
>maintain SLE 15 too, but if there's a big QoL enhancement, I'm okay with just
>Python 3.9+.
--
Reply to this email directly or view it on Gi
Backport `$RPM_BUILD_NCPUS`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1398345293
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-
Hilariously, `?!` used to not work in debbuild until it was noticed that it
worked in rpm, so it was implemented there. 😆
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2340#discussioncomment-4800878
You are receiving this becaus
`package-notes` is not an upstream RPM thing, so I'm not sure what benefit it
would be to have here...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2369#issuecomment-1407096967
You are receiving this because you are subscribed to this
Last I checked, the only thing I know of still using this mechanism is the
MinGW/Windows binary dependency generator. @rwmjones, did this get fixed
sometime in the last few years?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2373#is
> > add a versioned requires. (libcurl.so.4()(64bit) → libcurl.so.4()(64bit) >=
> > 4.8.0).
>
> The whole point of sonames is that it's NOT tied to versions but the soname
> abstraction, and this kind of dependency breaks that point.
I can think of one real-world case this would have broke: the
Also another hint is if you override `%_find_requires`, I think?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2373#issuecomment-1408550189
You are receiving this because you are subscribed to this thread.
Message ID:
> > I can think of one real-world case this would have broke: the SDL ->
> > sdl12-compat transition
>
> Would that have required Fedora to do more than either [bump the so
> version](https://github.com/libsdl-org/sdl12-compat/commit/883b629995e998e04b2ccd80a2c3ada46b0ce093)
> or, worst case, m
Ah, I misremembered when it came to where the weakness was. It had to do with
how the Steam Runtime "judges" library versions:
https://github.com/libsdl-org/sdl12-compat/issues/53#issuecomment-979976631
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manage
Could we adjust the RPM format so that things like multi-arch RPMs (i.e. RPMs
for macOS containing binaries that are universal binaries) could be correctly
indicated? That is, instead of assuming that we have a single "arch" for the
whole package, we identify the arches per file and collect the
I'm pretty sure this breaks the ability to swap between JACK and PipeWire-JACK
because the soname versioning construct is frozen in PipeWire-JACK but regular
JACK still gets version bumps.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/
> Well, anything which parses this output and makes use of it is broken. I
> shouldn't be using short ids for anything, particularly not in a script. So I
> think it's entirely reasonable to just change the output.
Unfortunately, we can't afford to do that. There are config management tools
and
probably not `tar`, but why not `pax`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5230414
You are receiving this because you are subscribed to this thread.
Message ID:
__
Somehow across the Autotools->CMake migration, we accidentally dropped the
configurability of the RPM vendor and always set it to "redhat".
Restore the configuration knob with a CMake variable and eliminate the circular
setting in the CMakeLists that blows away what the user sets.
You can view,
There are other bugs related to the platform setup, but I haven't figured out
how to fix them yet. 😖
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2440#issuecomment-1473808289
You are receiving this because you are subscribed to this t
Will do! 🫡
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2440#issuecomment-1473811240
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
> Another thought on the subject is that we could have a brp-script that turns
> absolute links into relative ones.
This might be possible with the
[`symlinks(1)`](https://www.mankier.com/1/symlinks) tool?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-ma
Also, another example of this is
[`dh_link`](https://salsa.debian.org/debian/debhelper/-/blob/main/dh_link).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/668#issuecomment-1473842326
You are receiving this because you are subscribed
I like that and would love to see an implementation for it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1474042087
You are receiving this because you are subscribed to this thread.
Message ID: __
I think this is going to need a versioned rpmlib capability, at least for SRPMs.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1690307448
You are receiving this because you are subscribed to this thread.
Message ID: __
Yes. I think Koji did at one point, and OBS does last I checked.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2633#issuecomment-1703681477
You are receiving this because you are subscribed to this thread.
Message ID:
cc: @ppisar
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2609#issuecomment-1715005576
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
cc: @ppisar
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2586#issuecomment-1715005987
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
In a conversation in
[`#devel:fedoraproject.org`](https://matrix.to/#/#devel:fedoraproject.org) with
@penguinpee, I realized that there's a potential quality of life improvement we
could look into making around `%setup`: Making it so we don't ever need to use
`-n`.
It started with asking about
Note that because of compatibility concerns, we'd probably want this new
behavior in a new macro.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1718404293
You are receiving this because you are subscribed to this thr
Keep in mind, we need a way to run it directly on the host, because all this
fanciness you're talking about doesn't exist on non-Linux platforms. In
particular, I would like to be able to run the test suite for RPM on macOS
still. 😅
--
Reply to this email directly or view it on GitHub:
https:
I will also point out there are openSUSE containers that use DNF too. 😉
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1718407495
You are receiving this because you are subscribed to this thread.
Message ID:
> None of this is inherently Linux specific, however to make it reasonably fast
> and efficient, you need something like OverlayFS which is currently only
> available on Linux (and
> https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921
> on some BSDs through fuse-ove
> 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 deprecated
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.
Mess
The fix is to _not_ clamp buildtime to SOURCE_DATE_EPOCH (i.e. don't set
`%use_source_date_epoch_as_buildtime 1`). We don't do this in Fedora and I
don't recommend any distribution to do it if they have a pipeline that relies
on the buildtime (and the openSUSE pipeline definitely does).
--
R
Oh, I misunderstood, this is about files inside of the package, not the RPM
itself.
I don't think this change is a valid one, because you're basically asking for
RPMs to be automatically because your process flow includes automatic rebuilds
that don't bump changelogs. That's what setting `SOURC
The correct fix for openSUSE is that the OBS builder should generate a new
`SOURCE_DATE_EPOCH` number to pass into the rpmbuild environment and you should
_not_ set `%source_date_epoch_from_changelog 1`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manag
Never.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733637577
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-m
401 - 500 of 1227 matches
Mail list logo
