11:13 a.m.
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary ==
Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
== Owner ==
* Name: [[User:pmatilai|Panu Matilainen]]
* Email: pmatilai(a)redhat.com
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in
particular this release addresses a whole class of symlink handling
related security issues, some with CVE's, from 2021. Other notable
improvements include
* A more intuitive conditional builds macro `%bcond`
* A more robust and secure `--restore` functionality
* Long-standing `%patch` quirks fixed
* Weak dependencies accept qualifiers like `meta` and `pre` now
* New interactive shell for working with macros (`rpmspec --shell`)
and embedded Lua (`rpmlua`)
* New `%conf` spec section for build configuration
* New `rpmuncompress` cli tool simplifies unpacking multiple sources
* Numerous macro improvements and fixes
* Numerous OpenPGP parser correctness and security fixes
== Benefit to Fedora ==
The main benefits of this release are increased security and packaging
experience improvements, see above for details.
== Scope ==
* Proposal owners:
** Rebase RPM
** Assist with dealing with incompatibilities
* Other developers:
** Test new release, report issues and bugs
* Release engineering: [https://pagure.io/releng/issue/10742 #10742]
* Policies and guidelines: N/A (not needed for this Change). Utilizing
new rpm features is subject to packaging guidelines but othe
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (no relation to current objectives)
== Upgrade/compatibility impact ==
There are no noteworthy compatibility issues with this release.
== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.
== User Experience ==
There are no major differences in the normal user experience.
== Dependencies ==
* No new dependencies are introduced in this release
* Other changes are known to be affected
* Library soname will not change so no rebuilds are required
== Contingency Plan ==
* Contingency mechanism: Revert back to RPM 4.17
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
Work-in-progress release notes at https://rpm.org/wiki/Releases/4.18.0
and reference manual at
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/ind...
== Release Notes ==
https://rpm.org/wiki/Releases/4.18.0
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
11:47 a.m.
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton <bcotton(a)redhat.com> wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary ==
Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
== Owner ==
* Name: [[User:pmatilai|Panu Matilainen]]
* Email: pmatilai(a)redhat.com
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in
particular this release addresses a whole class of symlink handling
related security issues, some with CVE's, from 2021. Other notable
improvements include
* A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an
extremely welcome change and I would like to shower praise upon
everyone who worked on it.
One thing I noticed while perusing the new docs: the documentation for
%autosetup is incomplete. The doc reads: "Generally %autosetup accepts
the same arguments as %setup does", but the section on %setup no
longer exists. Only the unique arguments for %autosetup are listed.
[1] https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html
12:14 p.m.
On Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton wrote:
* New interactive shell for working with macros (`rpmspec --shell`)
and embedded Lua (`rpmlua`)
That sounds cool. Can this be used to do standalone interpretation
of <lua> scriptlets? I'm wondering about the issue that we have with
rpm-ostree, which only supports bash scriptlets, so we end up rewriting
<lua> scriptlets and filetriggers to bash for the sake of rpm-ostree.
* New `%conf` spec section for build configuration
Any docs on this?
* New `rpmuncompress` cli tool simplifies unpacking multiple sources
* Numerous macro improvements and fixes
* Numerous OpenPGP parser correctness and security fixes
Zbyszek
3:27 a.m.
On 4/7/22 19:47, Stephen Gallagher wrote:
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
>
> https://fedoraproject.org/wiki/Changes/RPM-4.18
>
> == Summary ==
> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
>
> == Owner ==
>
> * Name: [[User:pmatilai|Panu Matilainen]]
> * Email: pmatilai(a)redhat.com
>
>
> == Detailed Description ==
>
> RPM 4.18 contains various improvements over previous versions, but in
> particular this release addresses a whole class of symlink handling
> related security issues, some with CVE's, from 2021. Other notable
> improvements include
> * A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an
extremely welcome change and I would like to shower praise upon
everyone who worked on it.
One thing I noticed while perusing the new docs: the documentation for
%autosetup is incomplete. The doc reads: "Generally %autosetup accepts
the same arguments as %setup does", but the section on %setup no
longer exists. Only the unique arguments for %autosetup are listed.
I don't think our docs ever covered %setup, that would've been max-rpm
more likely. Of course, %setup *should* be covered by our docs, and
ditto for %patch.
- Panu -
3:56 a.m.
On 4/7/22 20:14, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RPM-4.18
> * New interactive shell for working with macros (`rpmspec --shell`)
> and embedded Lua (`rpmlua`)
That sounds cool. Can this be used to do standalone interpretation
of <lua> scriptlets? I'm wondering about the issue that we have with
rpm-ostree, which only supports bash scriptlets, so we end up rewriting
<lua> scriptlets and filetriggers to bash for the sake of rpm-ostree.
Well, it's a Lua interpeter, and so you can use it to execute Lua
scripts from a file using the rpm embedded Lua interpreter so you'll
have the same extensions loaded. It's not the same as getting executed
from inside rpm transaction though because all sorts of context is
missing, and this is not the intended use-case of the thing. That said,
assuming the caller sets up scriptlet arguments and other state as per
expectations, I don't see why simple scriptlets would not work. File
triggers will not.
> * New `%conf` spec section for build configuration
Any docs on this?
There's a brief blurb in
https://rpm-software-management.github.io/rpm/manual/spec.html (not much
to say really), for rationale see
https://github.com/rpm-software-management/rpm/pull/1932
- Panu -
4:16 a.m.
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary ==
Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
* New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building.
Different build- and language ecosystems come with their own helper macros,
but rpm has helpers for autotools based builds such as itself which
typically look like this:
%conf
%configure
In context of autotools, sources usually bundle a configure script. To follow
the open source way (and ensure portability to new platform and include
autotools fixes), building from the real sources is desired. Hence I do my
best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
%prep %prep
%autosetup %autosetup
autoreconf -fi
%conf %conf
autoreconf -fi %configure
%configure
%build %build
%make_build %make_build
Please bear in mind that %prep usually contains other non-declarative twists
like pruning bundled code, correcting file permissions etc.
-- Petr
5:33 a.m.
On 4/8/22 12:16, Petr Pisar wrote:
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/RPM-4.18
>
> == Summary ==
> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
> * New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building.
Different build- and language ecosystems come with their own helper macros,
but rpm has helpers for autotools based builds such as itself which
typically look like this:
%conf
%configure
In context of autotools, sources usually bundle a configure script. To follow
the open source way (and ensure portability to new platform and include
autotools fixes), building from the real sources is desired. Hence I do my
best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
%prep %prep
%autosetup %autosetup
autoreconf -fi
%conf %conf
autoreconf -fi %configure
%configure
%build %build
%make_build %make_build
Please bear in mind that %prep usually contains other non-declarative twists
like pruning bundled code, correcting file permissions etc.
My personal opinion is that autoreconf, where used, belongs to %prep
because it can quite literally install bits required by the build system.
It's also something you only run once after unpacking the sources, not
every time you configure. Which suggests that they should be in
different sections. The same logic is applicable to other related steps.
- Panu -
5:44 a.m.
Dne 08. 04. 22 v 10:56 Panu Matilainen napsal(a):
On 4/7/22 20:14, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/RPM-4.18
>
>> * New interactive shell for working with macros (`rpmspec --shell`)
>> and embedded Lua (`rpmlua`)
>
> That sounds cool. Can this be used to do standalone interpretation
> of <lua> scriptlets? I'm wondering about the issue that we have with
> rpm-ostree, which only supports bash scriptlets, so we end up rewriting
> <lua> scriptlets and filetriggers to bash for the sake of rpm-ostree.
Well, it's a Lua interpeter, and so you can use it to execute Lua
scripts from a file using the rpm embedded Lua interpreter so you'll
have the same extensions loaded. It's not the same as getting executed
from inside rpm transaction though because all sorts of context is
missing, and this is not the intended use-case of the thing. That
said, assuming the caller sets up scriptlet arguments and other state
as per expectations, I don't see why simple scriptlets would not work.
File triggers will not.
I was just thinking about something similar yesterday in the context of
rhbz#2073170. The issue is that there is redhat-rpm-config macro using
Lua string patterns. So if there was a way to reuse the patterns also
from e.g. the build section, that would be useful.
Vít
6:17 a.m.
On Fri, Apr 8, 2022 at 6:34 AM Panu Matilainen <pmatilai(a)redhat.com> wrote:
On 4/8/22 12:16, Petr Pisar wrote:
> V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
>> https://fedoraproject.org/wiki/Changes/RPM-4.18
>>
>> == Summary ==
>> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
> [...]
>> * New `%conf` spec section for build configuration
>
> RPM documenation reads:
>
> In %conf, the unpacked sources are configured for building.
>
> Different build- and language ecosystems come with their own helper macros,
> but rpm has helpers for autotools based builds such as itself which
> typically look like this:
>
> %conf
> %configure
>
> In context of autotools, sources usually bundle a configure script. To follow
> the open source way (and ensure portability to new platform and include
> autotools fixes), building from the real sources is desired. Hence I do my
> best to call "autoreconf -fi" before %configure.
>
> Where should autoreconf be placed? %pre or %conf?
>
> %prep %prep
> %autosetup %autosetup
> autoreconf -fi
>
> %conf %conf
> autoreconf -fi %configure
> %configure
>
> %build %build
> %make_build %make_build
>
> Please bear in mind that %prep usually contains other non-declarative twists
> like pruning bundled code, correcting file permissions etc.
My personal opinion is that autoreconf, where used, belongs to %prep
because it can quite literally install bits required by the build system.
It's also something you only run once after unpacking the sources, not
every time you configure. Which suggests that they should be in
different sections. The same logic is applicable to other related steps.
I would disagree and suggest it go into %conf. My reasoning for this
is that autoreconf + configure is combined for most other build
systems and we want those to run in %conf, so consistency beckons that
we do the same here. It also ensures we don't need anything more than
tarball unpacking and patching dependencies for %prep.
--
真実はいつも一つ！/ Always, there's only one truth!
4:06 a.m.
On 4/8/22 14:17, Neal Gompa wrote:
On Fri, Apr 8, 2022 at 6:34 AM Panu Matilainen
<pmatilai(a)redhat.com> wrote:
>
> On 4/8/22 12:16, Petr Pisar wrote:
>> V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
>>> https://fedoraproject.org/wiki/Changes/RPM-4.18
>>>
>>> == Summary ==
>>> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
>> [...]
>>> * New `%conf` spec section for build configuration
>>
>> RPM documenation reads:
>>
>> In %conf, the unpacked sources are configured for building.
>>
>> Different build- and language ecosystems come with their own helper
macros,
>> but rpm has helpers for autotools based builds such as itself which
>> typically look like this:
>>
>> %conf
>> %configure
>>
>> In context of autotools, sources usually bundle a configure script. To follow
>> the open source way (and ensure portability to new platform and include
>> autotools fixes), building from the real sources is desired. Hence I do my
>> best to call "autoreconf -fi" before %configure.
>>
>> Where should autoreconf be placed? %pre or %conf?
>>
>> %prep %prep
>> %autosetup %autosetup
>> autoreconf -fi
>>
>> %conf %conf
>> autoreconf -fi %configure
>> %configure
>>
>> %build %build
>> %make_build %make_build
>>
>> Please bear in mind that %prep usually contains other non-declarative twists
>> like pruning bundled code, correcting file permissions etc.
>
> My personal opinion is that autoreconf, where used, belongs to %prep
> because it can quite literally install bits required by the build system.
>
> It's also something you only run once after unpacking the sources, not
> every time you configure. Which suggests that they should be in
> different sections. The same logic is applicable to other related steps.
>
I would disagree and suggest it go into %conf. My reasoning for this
is that autoreconf + configure is combined for most other build
systems and we want those to run in %conf, so consistency beckons that
we do the same here. It also ensures we don't need anything more than
tarball unpacking and patching dependencies for %prep.
I used "personal opinion" very much on purpose, as there would be as
many opinions on this as there are observers. My opinion is biased
towards what makes sense from a staged rpmbuild POV, for a --rebuild
end result all of this is academic.
- Panu -
9:04 a.m.
On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/RPM-4.18
>
> == Summary ==
> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
> * New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building.
Different build- and language ecosystems come with their own helper macros,
but rpm has helpers for autotools based builds such as itself which
typically look like this:
%conf
%configure
In context of autotools, sources usually bundle a configure script. To follow
the open source way (and ensure portability to new platform and include
autotools fixes), building from the real sources is desired. Hence I do my
best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
For me the important distinction is that %prep should *not* execute the
code from the package: it should just unpack, apply patches and fixups, change
permissions, etc. This all should be done using external tools, and not
scripts from the package itself. This way it is possible do 'fedpkg prep'
or equivalent and view the sources without executing any commands from
the package. So even if the package does not want to run on a given architecture,
or upstream does something stupid or hostile, %prep remains reliable.
(This also means that %prep should rather do less than more.)
If autoreconf is done using the external 'autoreconf' command, then
%prep seems appropriate. Some packages have ./autogen.sh or similar, and
that I'd put in one of the later sections.
Zbyszek
10:02 a.m.
While the autoreconf command is “external,” it does implicitly execute
m4 scripts, often including some that are included in the package source
distribution, in order to generate the configure script. Note also that
autogen.sh is rarely more than a trivial one-to-five-line wrapper around
autoreconf.
Sometimes autoreconf also needs m4 scripts that are installed with the
-devel packages of various dependencies. For example, gtk2-devel
provides /usr/share/aclocal/gtk-2.0.m4, which provides the
AM_PATH_GTK_2_0 macro, which can be used in dependent packages’
configure.ac files to generate GTK2 detection code. Such packages would
need gtk2-devel installed in order to run autoreconf. Sometimes copies
of these m4 files are provided with the dependent package sources, and
sometimes they aren’t.
This is why I don’t personally like autoreconf happening in %prep: it
can add arbitrary dependencies (not just autoconf/automake/libtool), and
I think it is valuable to be able to run “fedpkg prep” or similar
without installing extra dependencies on the packager’s system.
On 4/12/22 10:04, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
>> V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
>>> https://fedoraproject.org/wiki/Changes/RPM-4.18
>>>
>>> == Summary ==
>>> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
>> [...]
>>> * New `%conf` spec section for build configuration
>> RPM documenation reads:
>>
>> In %conf, the unpacked sources are configured for building.
>>
>> Different build- and language ecosystems come with their own helper macros,
>> but rpm has helpers for autotools based builds such as itself which
>> typically look like this:
>>
>> %conf
>> %configure
>>
>> In context of autotools, sources usually bundle a configure script. To follow
>> the open source way (and ensure portability to new platform and include
>> autotools fixes), building from the real sources is desired. Hence I do my
>> best to call "autoreconf -fi" before %configure.
>>
>> Where should autoreconf be placed? %pre or %conf?
> For me the important distinction is that %prep should *not* execute the
> code from the package: it should just unpack, apply patches and fixups, change
> permissions, etc. This all should be done using external tools, and not
> scripts from the package itself. This way it is possible do 'fedpkg prep'
> or equivalent and view the sources without executing any commands from
> the package. So even if the package does not want to run on a given architecture,
> or upstream does something stupid or hostile, %prep remains reliable.
> (This also means that %prep should rather do less than more.)
>
> If autoreconf is done using the external 'autoreconf' command, then
> %prep seems appropriate. Some packages have ./autogen.sh or similar, and
> that I'd put in one of the later sections.
>
> Zbyszek
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
10:22 a.m.
V Tue, Apr 12, 2022 at 04:04:35PM +0200, Zbigniew Jędrzejewski-Szmek napsal(a):
On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
> Where should autoreconf be placed? %pre or %conf?
For me the important distinction is that %prep should *not* execute the
code from the package: it should just unpack, apply patches and fixups, change
permissions, etc. This all should be done using external tools, and not
scripts from the package itself. This way it is possible do 'fedpkg prep'
or equivalent and view the sources without executing any commands from
the package. So even if the package does not want to run on a given architecture,
or upstream does something stupid or hostile, %prep remains reliable.
(This also means that %prep should rather do less than more.)
If autoreconf is done using the external 'autoreconf' command, then
%prep seems appropriate. Some packages have ./autogen.sh or similar, and
that I'd put in one of the later sections.
That's a good point. However, autoreconf tool expands m4 macros in
configure.ac and whatever aclocal macro directory or file provided with the
sources. I'm not an expert in m4, but according to a documentation m4 has
recursion and conditions, hence you can have an infinite loop. Thus, in the
the manner of your classification, I'd consider autoreconf not to be suitable
for %prep.
-- Petr
9:29 p.m.
On 4/12/22 11:22, Petr Pisar wrote:
V Tue, Apr 12, 2022 at 04:04:35PM +0200, Zbigniew Jędrzejewski-Szmek
napsal(a):
> On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
>> Where should autoreconf be placed? %pre or %conf?
>
> For me the important distinction is that %prep should *not* execute the
> code from the package: it should just unpack, apply patches and fixups, change
> permissions, etc. This all should be done using external tools, and not
> scripts from the package itself. This way it is possible do 'fedpkg prep'
> or equivalent and view the sources without executing any commands from
> the package. So even if the package does not want to run on a given architecture,
> or upstream does something stupid or hostile, %prep remains reliable.
> (This also means that %prep should rather do less than more.)
>
> If autoreconf is done using the external 'autoreconf' command, then
> %prep seems appropriate. Some packages have ./autogen.sh or similar, and
> that I'd put in one of the later sections.
>
That's a good point. However, autoreconf tool expands m4 macros in
configure.ac and whatever aclocal macro directory or file provided with the
sources. I'm not an expert in m4, but according to a documentation m4 has
recursion and conditions, hence you can have an infinite loop. Thus, in the
the manner of your classification, I'd consider autoreconf not to be suitable
for %prep.
-- Petr
M4 can also execute arbitrary shell commands.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
4:41 a.m.
On 4/7/22 19:13, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary ==
Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
FWIW, this is in rawhide now. Submitted yesterday already but some
bodhi/koji delay caused it to only go live today AFAICS.
As per the usual drill, if you so much as suspect a bug/regression in
rpm, don't dwell on it, just go ahead and file it. A few possible false
positives early on is a cheap price to pay compared to having to do
rebuilds en masse later.
- Panu -
4:53 a.m.
On Tue, Apr 26, 2022 at 11:50 AM Panu Matilainen <pmatilai(a)redhat.com> wrote:
On 4/7/22 19:13, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RPM-4.18
>
> == Summary ==
> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
>
FWIW, this is in rawhide now. Submitted yesterday already but some
bodhi/koji delay caused it to only go live today AFAICS.
As per the usual drill, if you so much as suspect a bug/regression in
rpm, don't dwell on it, just go ahead and file it. A few possible false
positives early on is a cheap price to pay compared to having to do
rebuilds en masse later.
I would have appreciated it if you at least waited with pushing it to
rawhide until the FESCo ticket was approved...
Fabio
2:23 a.m.
On 4/26/22 12:53, Fabio Valentini wrote:
On Tue, Apr 26, 2022 at 11:50 AM Panu Matilainen
<pmatilai(a)redhat.com> wrote:
>
> On 4/7/22 19:13, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/RPM-4.18
>>
>> == Summary ==
>> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
>>
>
> FWIW, this is in rawhide now. Submitted yesterday already but some
> bodhi/koji delay caused it to only go live today AFAICS.
>
> As per the usual drill, if you so much as suspect a bug/regression in
> rpm, don't dwell on it, just go ahead and file it. A few possible false
> positives early on is a cheap price to pay compared to having to do
> rebuilds en masse later.
I would have appreciated it if you at least waited with pushing it to
rawhide until the FESCo ticket was approved...
Indeed. I do know how the process goes, been through it many, many
times, and not sure what made me short-circuit it this time around.
Perhaps it was the distressed state of mind from our dog getting hit by
a car on Monday morning.
Apologies for that, and having seen the fesco meeting log - indeed it
would not hurt to say wait for explicit APPROVED stamp, no matter how
obvious it seems.
Oh, and the dog appears okay. Seems we were very, very lucky there.
- Panu -
3:36 a.m.
On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
> == Detailed Description ==
>
> RPM 4.18 contains various improvements over previous versions, but in
> particular this release addresses a whole class of symlink handling
> related security issues, some with CVE's, from 2021. Other notable
> improvements include
> * A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an
extremely welcome change and I would like to shower praise upon
everyone who worked on it.
Big +1 from me too, this is so good to see. Thanks Panu & all.
Regards, Joe
4:07 a.m.
On 27. 04. 22 10:36, Joe Orton wrote:
On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
> On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton <bcotton(a)redhat.com> wrote:
>> == Detailed Description ==
>>
>> RPM 4.18 contains various improvements over previous versions, but in
>> particular this release addresses a whole class of symlink handling
>> related security issues, some with CVE's, from 2021. Other notable
>> improvements include
>> * A more intuitive conditional builds macro `%bcond`
>
> I looked this up[1] because it caught my attention. This is an
> extremely welcome change and I would like to shower praise upon
> everyone who worked on it.
Big +1 from me too, this is so good to see. Thanks Panu & all.
I like this so much I've opened Fedora 36 and 35 backports:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/182
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/183
Will also try to see if this is technically possible in c9s.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:53 a.m.
On Wed, Apr 27, 2022 at 5:08 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 27. 04. 22 10:36, Joe Orton wrote:
> On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
>> On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton <bcotton(a)redhat.com> wrote:
>>> == Detailed Description ==
>>>
>>> RPM 4.18 contains various improvements over previous versions, but in
>>> particular this release addresses a whole class of symlink handling
>>> related security issues, some with CVE's, from 2021. Other notable
>>> improvements include
>>> * A more intuitive conditional builds macro `%bcond`
>>
>> I looked this up[1] because it caught my attention. This is an
>> extremely welcome change and I would like to shower praise upon
>> everyone who worked on it.
>
> Big +1 from me too, this is so good to see. Thanks Panu & all.
I like this so much I've opened Fedora 36 and 35 backports:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/182
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/183
Will also try to see if this is technically possible in c9s.
It should be possible to put it in epel-rpm-macros at the worst, no?
(Related: can we get a backport to EPEL 8 and EPEL 9?)
11:09 a.m.
On 27. 04. 22 17:53, Stephen Gallagher wrote:
On Wed, Apr 27, 2022 at 5:08 AM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
>
> On 27. 04. 22 10:36, Joe Orton wrote:
>> On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
>>> On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton <bcotton(a)redhat.com> wrote:
>>>> == Detailed Description ==
>>>>
>>>> RPM 4.18 contains various improvements over previous versions, but in
>>>> particular this release addresses a whole class of symlink handling
>>>> related security issues, some with CVE's, from 2021. Other notable
>>>> improvements include
>>>> * A more intuitive conditional builds macro `%bcond`
>>>
>>> I looked this up[1] because it caught my attention. This is an
>>> extremely welcome change and I would like to shower praise upon
>>> everyone who worked on it.
>>
>> Big +1 from me too, this is so good to see. Thanks Panu & all.
>
> I like this so much I've opened Fedora 36 and 35 backports:
>
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/182
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/183
>
> Will also try to see if this is technically possible in c9s.
It should be possible to put it in epel-rpm-macros at the worst, no?
(Related: can we get a backport to EPEL 8 and EPEL 9?)
What I've meant by "technically possible": Does the RPM version in EL 9
support
the syntax used in the macro?
If it does, it can go to EPEL 9 and even to c9s eventually, if accepted. If it
doesn't, we might need to use a different syntax which would require more work.
This also applies to EL 8, but I suspect even more problems there.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:49 a.m.
On 4/27/22 19:09, Miro Hrončok wrote:
On 27. 04. 22 17:53, Stephen Gallagher wrote:
> On Wed, Apr 27, 2022 at 5:08 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>>
>> On 27. 04. 22 10:36, Joe Orton wrote:
>>> On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
>>>> On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
>>>>> == Detailed Description ==
>>>>>
>>>>> RPM 4.18 contains various improvements over previous versions, but
in
>>>>> particular this release addresses a whole class of symlink handling
>>>>> related security issues, some with CVE's, from 2021. Other
notable
>>>>> improvements include
>>>>> * A more intuitive conditional builds macro `%bcond`
>>>>
>>>> I looked this up[1] because it caught my attention. This is an
>>>> extremely welcome change and I would like to shower praise upon
>>>> everyone who worked on it.
>>>
>>> Big +1 from me too, this is so good to see. Thanks Panu & all.
>>
>> I like this so much I've opened Fedora 36 and 35 backports:
>>
>> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/182
>> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/183
>>
>> Will also try to see if this is technically possible in c9s.
>
> It should be possible to put it in epel-rpm-macros at the worst, no?
> (Related: can we get a backport to EPEL 8 and EPEL 9?)
What I've meant by "technically possible": Does the RPM version in EL 9
support the syntax used in the macro?
If it does, it can go to EPEL 9 and even to c9s eventually, if accepted.
If it doesn't, we might need to use a different syntax which would
require more work. This also applies to EL 8, but I suspect even more
problems there.
The %bcond macro relies on a %[] expression which requires rpm >= 4.16,
so EL9 should be okay, older ones wont work.
- Panu -
722
days inactive
743
days old
21 comments
12 participants
participants (12)
-
Ben Beasley -
Ben Cotton -
Demi Marie Obenour -
Fabio Valentini -
Joe Orton -
Miro Hrončok -
Neal Gompa -
Panu Matilainen -
Petr Pisar -
Stephen Gallagher -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek