Cool, thank you very much. I hoped it would be possible without modified RPM
itself. Anyway, thanks for finishing it!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Adjusted the patch to work with the new patch_nums variable. Also renamed the
params to -m and -M as suggested above.
@pemensik: Thanks for your work!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #626 via f00bb5be9caa62220c6aeaf3f7264840d5c089e3.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
We used to do this (milestones) back in the Trac days but it didn't seem worth
a whole lot to anybody.
Doesn't mean we couldn't try it, I do understand the problem of rpm.org plans
being opaque to the outside when they tend to be opaque on the inside as well...
--
You are receiving this
...but... after discussing with @ffesti, the only backwards compatible option
is 3), people could legitimately have their own macros iterating on
sources/patches and those would break if we change it as per 1/2.
--
You are receiving this because you are subscribed to this thread.
Reply to this
> Do you know how difficult would it be to link patch names back to original
> number?
It's a bit harder than it seems on the outset. Various options:
1. extend the rpmlua interface to support arbitrary objects (to allow storing
number alongside the name)
2. extend the rpmlua interface to allow
Closed #634.
--
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/634#event-2151356974___
Rpm-maint mailing list
Pushed as 0ac97701560ca65d53880bacdf32b375d42c18a8 with amened commit message.
Thanks for the patch!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
For external people and other contributors it is not visible when next release
of RPM will happen and what features will be there.
GitHub provides "Milestone" feature, so could you create 4.15 milestone and
assign Pull Requests and Issues which are planned for that release? And
possibly
If the whitespace changes are intentionally included, the commit message should
mention them too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This is not how we roll as you should know perfectly well, please respect that.
Asking for external feedback (eg on distro devel forums) ideas is of course
fine, a change proposal is quite something else.
If you want to see things done differently, start by talking to us. Stepping
over
> This is NOT a time to submit Fedora features.
So when is the time? Submitting change proposals help to gather feedback from
community and get additional people on board for discussions.
Unless you don't want any external people to be involved, implement something
and then wait another 10
Closed #635.
--
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/635#event-2151126871___
Rpm-maint mailing list
Err, what? You trimmed out the relevant part of that quote:
> You can of course define a macro that contains and %if-%else-%endif but that
> will only work as expected when expanded in a spec.
That macro is part of automated debuginfo generation and is only ever invoked
in spec context, where
14 matches
Mail list logo
