Yes, I get that you have repetitive sections. Like I've been telling you:
script it (build scriptlets are shell scripts, you can have functions in there)
or macroize it, with parameters to allow for the variety. The package name in
macros would not be helpful here at all.
--
Reply to this emai
@teknoraver pushed 1 commit.
61abc03412741efe05730e5d2d405c155a9ceac4 add build directory auto path to
%autosetup
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2859/files/170bfc9dcd8e04b5a6681a56dbaa9414f6d3a2a5..61abc03412741efe05730e5d2d405c155a9ceac4
You are rece
I'd been meaning to come back to this quite a while ago, but I got sick and
that put me out for a *long* time.
I still think that *something* should be done with the ELF dep generator, but
more discussion would be helpful.
I mentioned that Debian's approach came up in discussions. On one hand,
Guess we want `%__bcond_default` and `%bcond_default` for declaring the
`%bcond_default_foo` macro even if that is slightly silly.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1919596356
You are receiving this because
Well turns out this actually works. But may be not the way you expected... and
that's why we need docs.
As far as I understand this `%bcond_default` is just a helper macro (and should
be prepended with `__`) and the user/distro is supposed to declare
%bcond_default_foo manually. With that thing
What about adding those two archives in `tree/master/tests/data/SOURCES` and
add a test to `tests/rpmbuild.at`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2859#issuecomment-1919422189
You are receiving this because you are subscribed
@gordonmessmer, this PR seems to have stalled a bit. Do you still wish to have
it reviewed and merged in its current state, or are they changes needed?
In any case, I'll convert it to a draft now as there's some level of
uncertainty around the right approach (based on reading the recent comments
This PR is wrong and is not solving th issue.
It is the problem that macros used with `%bcond_with foo`/`%bcond_without foo`
like `%{?with_foo}` and `%{?without_foo}` are using presence or not that macro.
If you will look closer on macros file
```spec
# Internally, the `--with foo` option defines
> 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.
That is incorrect. Pass the same 2 environment variables and it is
reproducible. Same as before, just one additional variable.
T
At this stage, I don't want to really constrain myself by `Source` being
attached to subpackage or not. But if there is space for [append / prepend
scriptlets](https://github.com/rpm-software-management/rpm/pull/2728), then I
don't see the package specific scriptlets to being way off.
--
Reply
`__embedded_file_attrs`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1918940894
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
I think the issue here that they can be both overriding existing ones or being
an add-on. This makes it difficult to find a good name that covers both cases.
OK, technically the macro doesn't override existing file attrs.
Overriding/defining the macros does. So here we are registering file attr
Well, sub package definitions are normal preambles that can contain everything
the main preamble can. But that doesn't mean those (e.g. `Source:`) directives
are somehow attached to that sub package. Global directives are global no
matter where they are.
The build scripts also are global. Attac
Oh yup, sorry for leaving you hanging in the air here. Technically this looks
pretty good (but yup, could use a test-case). What this needs now is us
thinking it all through, taking other plans into consideration and see how the
details fit in with those. Don't despair in the meanwhile :sweat_sm
I think I like "override" better. Probably because it emphasizes the out of
order operation.
We also need to add this to `manual/conditionalbuilds.md` as soon as we decided
on a name.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405
This looks pretty good now.
I wonder if the examples in the commit message would better be moved into a
test case.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2859#issuecomment-1918773263
You are receiving this because you are subscr
Merged #2881 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2881#event-11652657021
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
@pmatilai pushed 1 commit.
8b8f905d29b6bf92fd36f712ef55a59360353405 Fix an UB in expression code (when
built without -fno-strict-overflow)
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2881/files/28fd7275f38c33240beabf946baf1a6975e680db..8b8f905d29b6bf92fd36f712ef55
Similar to ASAN, now that we can this is a nice and cheap way to keep compiler
gremlins at bay.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2881
-- Commit Summary --
* Add a build option for enabling undefined behavior
Merged #2879 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2879#event-11652142792
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
20 matches
Mail list logo
