I'd prefer a name that indicates the spec/package specifity somehow. @ffesti ,
@dmnks , thoughts, other ideas?
And yeah adding that empty file with just a comment on the purpose would
actually be even more simple.
--
Reply to this email directly or view it on GitHub:
BTW, we could just use Podman in the CI now, too. The Ubuntu version deployed
there is recent enough to have Podman in a recent-ish version, too, and is even
installed by default.
The only "advantage" (or rather a side effect) of Docker is that it must run
with root privileges, in which case
Hmm, so I just tried a build with `-DCMAKE_INSTALL_PREFIX=/usr` and it worked
fine :confused:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2733#issuecomment-1780653835
You are receiving this because you are subscribed to this thread.
@pmatilai pushed 4 commits.
23e90b1bb6f2a743291c546db316690b73e0ed07 Make macro name first character check
more obvious
6b4e5ac42a8aac741eb280e88f9731ca410b02a7 Validate the entire macro name in
validName()
e25c0b0fc600a1459c6456a66eac22098fa918f0 Add support for macro aliases
Okay with offline debugging with @dmnks , the difference came from me not
having `buildah` installed, and cmake reporting
> -- Using mktree backend: podman (native: OFF)
After installing buildah that changes to ON, and the test-suite passes. So the
apparent configuration leakage is an issue
Hmm. I'm getting a LOT of failures when running this as "make check" locally on
F38, before and after doing an 'rm -rf *' of the entire build tree:
> Subject: [rpm 4.19.90] rpmtests: 5 116 117 149 165 297 298 401 403 404 407
> 408 413 431 434 435 436 437 438 439 440 442 443 444 445 446 447 448
Could you please try a completely new build in a separate build dir? Just to
rule out any local build configuration.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2733#issuecomment-1780659545
You are receiving this because you are
Tweaked a the commit message a bit to include rationale as well and applied
manually (commit b3449a0774487a091bbe59e821b4004b06d4fa66)
Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2736#issuecomment-1780523751
Closed #2736.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2736#event-10775583970
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
> Hmm. I'm getting a LOT of failures when running this as "make check" locally
> on F38, before and after doing an 'rm -rf *' of the entire build tree:
Ugh, I haven't tested the non-default (`/usr/local`) prefix... *This* is why
PRs are actually valuable, it seems like :sweat_smile: Of
Oh, you mentioned you recreated the entire build tree (not just `tests/`),
nevermind then... myster deepends :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2733#issuecomment-1780688645
You are receiving this because you are
Hmm, I'll retest after lunch. I also have `-DRPM_VENDOR=redhat` in my build
script, and I probably took out that too :thinking:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2733#issuecomment-1780715518
You are receiving this because
Looks actually quite nice and surprisingly straight forward.
I wonder if we should do an announcement if we really want to drop %patchN so
distributions have a bit more time to prepare.
--
Reply to this email directly or view it on GitHub:
OK, tried with a couple more config options, namely:
```
export CFLAGS="-Og -g"
cmake \
-DCMAKE_INSTALL_PREFIX=/usr \
-DENABLE_WERROR=ON \
-DENABLE_BDB_RO=ON \
-DWITH_FSVERITY=ON \
-DWITH_IMAEVM=ON \
-DWITH_FAPOLICYD=ON \
-DRPM_VENDOR=redhat
I guess you need to do that 'rm -rf *' of the build tree for the prefix to
really take effect - that way I can reliably reproduce the failures.
Looking at the build log makes it kinda obvious what is going on. With a
`-DCMAKE_INSTALL_PREFIX=/usr` build, the build inside the image ends up
Merged #2732 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2732#event-10775540106
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I don't have a strong opinion either, this was just a statistical observation
:smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2732#issuecomment-1780517908
You are receiving this because you are subscribed to this thread.
Closed #2731 as completed via #2732.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2731#event-10775540279
You are receiving this because you are subscribed to this thread.
Message ID:
___
Closed #2423 as completed via b3449a0774487a091bbe59e821b4004b06d4fa66.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2423#event-10775576146
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai pushed 1 commit.
1434a4e12bd723278bc16b2c7b228f0c65ba9eb1 Add proper documentation about our
different macro types and scopes
--
View it on GitHub:
Added more elaborate documentation. In order to document the aliases I needed
to document all sorts of other macro behavior first, which is not a bad thing...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2722#issuecomment-1780700705
I actually did precisely that, removed the whole build dir and created it from
scratch, and yet, it works :laughing: But, one important difference perhaps is
that I did *not* configure anything besides the prefix, i.e:
```
$ mkdir _build
$ cd _build/
$ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
$ make
In general, less build dependencies is better but only if skipping buildah is
truly trivial. I don't want us to sink yet more time into *that*.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2733#issuecomment-1780851143
You are
The manual explicitly states:
```
Alternatively, you can test the presence (or lack thereof) of %with_foo macros
which is nicer in other situations, e.g.:
%configure \
%{?with_static:--enable-static} \
%{!?with_static:--disable-static}
Always test for the with-condition, not the
Closed #1929 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1929#event-10778549244
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Yeah, after all the years of refactoring the final piece doesn't actually look
like much :laughing:
We're already issuing deprecation warnings from 4.18 and 4.19, so when 4.20
lands in the first distros sometime next year it wont come out of the great big
blue, but sure, banging some drums
Indeed, sorry for not pointing that (new requirement) out in the beginning,
somehow that didn't even cross my mind :smile:
I can now reproduce this in non-native mode with a different prefix. Something
is leaking into the image even if it shouldn't. Will fix.
Meanwhile, I'm thinking if we
Just FTR, culprit found, it's because the `rpmtests.sh` wrapper runs `rpmtests`
from the local build directory if it exists, even in non-native mode. Working
on a fix now.
--
Reply to this email directly or view it on GitHub:
Yup, I'll see if it can be done with Podman just as easily and go from there.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2733#issuecomment-1780857838
You are receiving this because you are subscribed to this thread.
Message ID:
while is document , is not intuitive
- %if %{without static} works
- but %{?without_static: ... } doesn't work
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1929#issuecomment-1781075023
You are receiving this because you are
And for some reason you insist on using the one that doesn't work, and isn't
documented? That's not intuitive to me either.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1929#issuecomment-1781094583
You are receiving this because you
I don't use it but I found many people that use it (wrongly)
https://sourcegraph.com/search?q=context:global+r:src.fedoraproject.org+file:.*%5C.spec%24+%5C%3Fwithout_=regexp=yes=0=repo
--
Reply to this email directly or view it on GitHub:
May be people like this version better.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2728#issuecomment-1781371354
You are receiving this because you are subscribed to this thread.
Message ID:
@ffesti pushed 1 commit.
a8b4e5be21cae2f980e75bc528bff0405ec64689 Reword spec.md change
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2728/files/39973be09ef2f0217177fd2afc65cabd1cd3945d..a8b4e5be21cae2f980e75bc528bff0405ec64689
You are receiving this because you are
34 matches
Mail list logo
