Re: [EPEL-devel] Re: RFC: generating openssl3 packages from openssl spec
On Wed, Nov 10, 2021 at 03:50:44PM -0800, Michel Alexandre Salim wrote:
> On Wed, 2021-11-10 at 15:48 -0800, Michel Alexandre Salim wrote:
> >
> > This shows the minimum changes needed to:
> > - have openssl3-libs parallel installable with openssl-libs (tested in
> > mock for x86_64)
> > - mark the base, devel, and perl subpackages as conflicting
> > - openssl3 and openssl both ship binaries in %{_bindir}
> > - ditto with openssl3-perl and openssl-perl
> > - openssl3-devel and openssl-devel both ship headers and includes
> > with the same names
> >
> And of course I forgot to paste in the commit:
> https://gitlab.com/michel-slm/openssl3/-/commit/3649e51f898dbe1d97695cd8aca206c262a03617
>
It's been 2 days, so I'm assuming I'm not doing anything insanely silly
here. I've put up the package for review:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2022907
cc:ing Sahana who is driving the OpenSSL 3 migration in Fedora. Sahana,
would it make sense to have this in Fedora 34 and 35 as well?
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Thu, Aug 12, 2021 at 06:14:57PM -0700, Michel Alexandre Salim via devel
wrote:
> On Thu, Aug 12, 2021 at 05:23:18PM -0700, Michel Alexandre Salim via devel
> wrote:
> > On Wed, Aug 11, 2021 at 10:56:39AM +0300, Panu Matilainen wrote:
> > > On 8/10/21 8:53 PM, Ankur Sinha wrote:
> > > > On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote:
> > > > > Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a):
> > > > > > This is now implemented on Rawhide; Fedora updates are in testing:
> > > > >
> > > > > Where is it documented?
> > > > >
> > > > > I suggest one of these
> > > > >
> > > > > https://rpm-packaging-guide.github.io/
> > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/
> > > >
> > > > That would be great. I was trying to put %limit_build at the top of my
> > > > spec and kept getting errors. Then I looked at the mcrouter spec and
> > > > realised this needs to go into the %build section XD
> > >
> > > Yes, the macro is a strange as it mixes rpm macro language and shell
> > > language, relying on some rather subtle aspects of how spec parsing and
> > > macros work and has to be placed in a shell section. If you ask me, it's
> > > asking for trouble.
> > >
> > > Setting RPM_BUILD_NCPUS environment should achieve the same without
> > > requiring the twisty %global override which looks like it may break
> > > _smp_build_ncpus use in later sections (but I may be missing something
> > > there)
> > >
> > So - I did try exporting RPM_BUILD_NCPUS earlier, and having tried it
> > again, could not figure out how to set that definition from within a
> > macro. Any idea?
> >
> > openSUSE's macro overrides %_smp_mflags instead, which ... seems to work
> > for them, but I agree that we should rather use an environment variable
> > instead.
> >
> Some findings:
> - overriding %_smp_mflags works. But I have to use %global - %define
> does not work - and that triggers some ugly warnings at every build
> - setting RPM_BUILD_NCPUS (or, similarly, %_smp_ncpus_max) does not work
> since %_smp_build_ncpus is already defined by then
>
> Seems like the proper fix here is to either:
> - try and get this macro into RPM proper, so we can have %limit_build
> declared at the top of the spec. This will likely push the change back
> to F36 at the earliest, and would make it hard to retrofit on existing
> releases, unless we want to carry out-of-tree patches.
> - _smp_build_ncpus also seems to be defined per platform, even though
> the definition is mostly identical, so this will be a bit messy
> - change the usage, and require users who want to limit the build to do
> something like this:
>
> %make_build %{limit_build -m 4096} -- with %limit_build used as a
> %function that spits out the relevant -j override
>
Updated pull request, using the latter option:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141
The macro is now rewritten in Lua, since I can't coerce the shell
definition to just output a value. Tested locally with mock (I had to
copy fedora-34-x86_64 to fedora-35-x86_64 as the Rawhide target is
currently failing on GPG verification).
- if limit_build computes a number that is higher than %_smp_build_ncpus
it outputs nothing
- if it computes a value that is smaller, it outputs '-j'
- if it computes a value less than 1 it outputs '-j1'
Tested with mcrouter locally and setting the memory requirement to some
ridiculous value (-m 409600) I do end up with a single-core build.
Inline documentation is provided, once the PR is reviewed and this is
built for Rawhide I'll update the packaging guideline.
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Thu, Aug 12, 2021 at 05:23:18PM -0700, Michel Alexandre Salim via devel
wrote:
> On Wed, Aug 11, 2021 at 10:56:39AM +0300, Panu Matilainen wrote:
> > On 8/10/21 8:53 PM, Ankur Sinha wrote:
> > > On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote:
> > > > Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a):
> > > > > This is now implemented on Rawhide; Fedora updates are in testing:
> > > >
> > > > Where is it documented?
> > > >
> > > > I suggest one of these
> > > >
> > > > https://rpm-packaging-guide.github.io/
> > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/
> > >
> > > That would be great. I was trying to put %limit_build at the top of my
> > > spec and kept getting errors. Then I looked at the mcrouter spec and
> > > realised this needs to go into the %build section XD
> >
> > Yes, the macro is a strange as it mixes rpm macro language and shell
> > language, relying on some rather subtle aspects of how spec parsing and
> > macros work and has to be placed in a shell section. If you ask me, it's
> > asking for trouble.
> >
> > Setting RPM_BUILD_NCPUS environment should achieve the same without
> > requiring the twisty %global override which looks like it may break
> > _smp_build_ncpus use in later sections (but I may be missing something
> > there)
> >
> So - I did try exporting RPM_BUILD_NCPUS earlier, and having tried it
> again, could not figure out how to set that definition from within a
> macro. Any idea?
>
> openSUSE's macro overrides %_smp_mflags instead, which ... seems to work
> for them, but I agree that we should rather use an environment variable
> instead.
>
Some findings:
- overriding %_smp_mflags works. But I have to use %global - %define
does not work - and that triggers some ugly warnings at every build
- setting RPM_BUILD_NCPUS (or, similarly, %_smp_ncpus_max) does not work
since %_smp_build_ncpus is already defined by then
Seems like the proper fix here is to either:
- try and get this macro into RPM proper, so we can have %limit_build
declared at the top of the spec. This will likely push the change back
to F36 at the earliest, and would make it hard to retrofit on existing
releases, unless we want to carry out-of-tree patches.
- _smp_build_ncpus also seems to be defined per platform, even though
the definition is mostly identical, so this will be a bit messy
- change the usage, and require users who want to limit the build to do
something like this:
%make_build %{limit_build -m 4096} -- with %limit_build used as a
%function that spits out the relevant -j override
Thoughts?
Thanks,
--
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Wed, Aug 11, 2021 at 10:56:39AM +0300, Panu Matilainen wrote: > On 8/10/21 8:53 PM, Ankur Sinha wrote: > > On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote: > > > Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a): > > > > This is now implemented on Rawhide; Fedora updates are in testing: > > > > > > Where is it documented? > > > > > > I suggest one of these > > > > > > https://rpm-packaging-guide.github.io/ > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > > > That would be great. I was trying to put %limit_build at the top of my > > spec and kept getting errors. Then I looked at the mcrouter spec and > > realised this needs to go into the %build section XD > > Yes, the macro is a strange as it mixes rpm macro language and shell > language, relying on some rather subtle aspects of how spec parsing and > macros work and has to be placed in a shell section. If you ask me, it's > asking for trouble. > > Setting RPM_BUILD_NCPUS environment should achieve the same without > requiring the twisty %global override which looks like it may break > _smp_build_ncpus use in later sections (but I may be missing something > there) > So - I did try exporting RPM_BUILD_NCPUS earlier, and having tried it again, could not figure out how to set that definition from within a macro. Any idea? openSUSE's macro overrides %_smp_mflags instead, which ... seems to work for them, but I agree that we should rather use an environment variable instead. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Wed, Aug 11, 2021 at 01:53:51PM +0300, Panu Matilainen wrote: > On 8/11/21 11:19 AM, Ankur Sinha wrote: > > On Wed, Aug 11, 2021 10:56:39 +0300, Panu Matilainen wrote: > > > On 8/10/21 8:53 PM, Ankur Sinha wrote: > > > > On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote: > > > > > Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a): > > > > > > This is now implemented on Rawhide; Fedora updates are in testing: > > > > > > > > > > Where is it documented? > > > > > > > > > > I suggest one of these > > > > > > > > > > https://rpm-packaging-guide.github.io/ > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > > > > > > > That would be great. I was trying to put %limit_build at the top of my > > > > spec and kept getting errors. Then I looked at the mcrouter spec and > > > > realised this needs to go into the %build section XD > > > > > > Yes, the macro is a strange as it mixes rpm macro language and shell > > > language, relying on some rather subtle aspects of how spec parsing and > > > macros work and has to be placed in a shell section. If you ask me, it's > > > asking for trouble. > > > > > > Setting RPM_BUILD_NCPUS environment should achieve the same without > > > requiring the twisty %global override which looks like it may break > > > _smp_build_ncpus use in later sections (but I may be missing something > > > there) > > > > I think it does. > > Yep. It breaks debuginfo processing for one, which is a showstopper. Builds > fail with "Empty %files file .../debugsourcefiles.list" and the like. > Ugh, so that's what happened. My bad. -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
Hi all, On Wed, Aug 11, 2021 at 10:56:39AM +0300, Panu Matilainen wrote: > On 8/10/21 8:53 PM, Ankur Sinha wrote: > > On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote: > > > Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a): > > > > This is now implemented on Rawhide; Fedora updates are in testing: > > > > > > Where is it documented? > > > > > > I suggest one of these > > > > > > https://rpm-packaging-guide.github.io/ > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > > > That would be great. I was trying to put %limit_build at the top of my > > spec and kept getting errors. Then I looked at the mcrouter spec and > > realised this needs to go into the %build section XD > > Yes, the macro is a strange as it mixes rpm macro language and shell > language, relying on some rather subtle aspects of how spec parsing and > macros work and has to be placed in a shell section. If you ask me, it's > asking for trouble. > > Setting RPM_BUILD_NCPUS environment should achieve the same without > requiring the twisty %global override which looks like it may break > _smp_build_ncpus use in later sections (but I may be missing something > there) > I'll revise, thanks! The documentation is forthcoming, personal life was getting in the way over the past few weeks. Hopefully using RPM_BUILD_NCPUS will obviate having to declare this in `%build` -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Tue, Jun 29, 2021 at 04:25:13PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros > > == Summary == > Introduce macros, similar to openSUSE's > [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints > memory-constraints]), for optionally limiting build parallelism for > build-time memory-bound packages > > == Owner == > * Name: [[User:salimma|Michel Alexandre Salim]] > * Email: michel AT michel-slm DOT name > > > == Detailed Description == > Some source packages have a memory usage per build thread higher than > the RAM:CPU ratio available in some of our builders. Further, this > ratio can be different for different build server on different > architectures. > > At the moment, such packages > ([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49733beff6b3/f/ceph.spec#_1269-1390 > ceph], > [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd108ce9874543f2d/f/chromium.spec#_3-14 > chromium], > [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082358745c7882c86/f/mcrouter.spec#_68-82 > mcrouter]) have to implement their own logic for determining the safe > amount of parallelism, and redefine `_smp_build_ncpus`. > > When this proposal is implemented, they can instead declaratively > specify the amount of RAM needed per build thread, e.g. > > %limit_build -m 8192 > > for declaring a build thread should be allocated 8GB of RAM. This is now implemented on Rawhide; Fedora updates are in testing: F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7c42e41506 F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a5cd9680ba Works fine with `mcrouter`: https://koji.fedoraproject.org/koji/buildinfo?buildID=1812360 The EPEL changes (to `epel-rpm-macros`) are committed and built, but not published to Bodhi yet since Miro's `%py3_check_import` updates are still in flight. Could the Ceph maintainers help test this too? I looked at the spec, and changing it seems straightforward, *but* I don't know how much the spec is meant to be kept in sync with openSUSE (there's some openSUSE centric definitions there). `%limit_build` could be used on both openSUSE and Fedora now, but the SUSE variant is slightly different (it seems to be inspired by Ceph to begin with): it considers as available memory both physical and swap, whereas Ceph (and the version I added to `redhat-rpm-config` / `epel-rpm-macros`) only considers physical memory, which seems more reasonable. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Wed, Jun 30, 2021 at 08:54:11AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jun 29, 2021 at 04:25:13PM -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros > > > > == Summary == > > Introduce macros, similar to openSUSE's > > [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints > > memory-constraints]), for optionally limiting build parallelism for > > build-time memory-bound packages > > > > == Owner == > > * Name: [[User:salimma|Michel Alexandre Salim]] > > * Email: michel AT michel-slm DOT name > > > > > > == Detailed Description == > > Some source packages have a memory usage per build thread higher than > > the RAM:CPU ratio available in some of our builders. Further, this > > ratio can be different for different build server on different > > architectures. > > > > At the moment, such packages > > ([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49733beff6b3/f/ceph.spec#_1269-1390 > > ceph], > > [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd108ce9874543f2d/f/chromium.spec#_3-14 > > chromium], > > [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082358745c7882c86/f/mcrouter.spec#_68-82 > > mcrouter]) have to implement their own logic for determining the safe > > amount of parallelism, and redefine `_smp_build_ncpus`. > > > > When this proposal is implemented, they can instead declaratively > > specify the amount of RAM needed per build thread, e.g. > > > > %limit_build -m 8192 > > > > for declaring a build thread should be allocated 8GB of RAM. > > > > Since Koji supports > > [https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-changes > > setting default values for macros], there will be a macro for the > > default memory limit (name TBD) that, if set, will be used to cap > > `_smp_build_ncpus` unless overridden by `%limit_build -m`. > > Is the default required? Wouldn't it be enough to make '%limit_build -m 8192' > *lower* _smp_build_ncpus if it detects that not enough memory is present? > I.e. keep status quo by default, optionally lower (and only lower) > _smp_build_ncpus > when '%limit_build -m …' is used? > That was meant to be optional -- and if it's not set, the status quo is kept anyway. I'll revise the documentation. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Macro to smoke-test-import a Python module in %check
On Wed, Jul 14, 2021 at 07:27:52PM +0200, Miro Hrončok wrote: > On 08. 07. 21 16:48, Miro Hrončok wrote: > > On 29. 06. 21 8:28, Felix Schwarz wrote: > > > > > > Am 28.06.21 um 21:44 schrieb Miro Hrončok: > > > > The semantics is quite simple: > > > > > > > > > > > > %check > > > > %py3_check_import mymodule mymodule.submodule > > > > > > Looks great! Thank you. > > > > > > Please let us know when we should start adding that to our Python > > > packages. :-) > > > > Feel free to test it out in rawhide. > > > > If there is no more feedback, I'll initiate the backports next week. > > > EPEL 8: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/31 > > EPEL 7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/32 > Tested the EPEL updates: EPEL 8 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-dfd462a782 EPEL 7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e3b1cc2b6e with this `python-dialog` PR: https://src.fedoraproject.org/rpms/python-dialog/pull-request/1 Works fine. If someone wants to help test, the needed `epel-rpm-macros` is in buildroot override, and here's a good way to find EPEL specs that do not have checks yet: wget -cN https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz tar xf rpm-specs-latest.tar.xz cd rpm-specs grep -l epel $(grep -L '%check' python*.spec) currently resulting in: python-bitarray.spec python-dialog.spec python-docker.spec python-epel-rpm-macros.spec python-fedora.spec python-flask-login.spec python-graphitesend.spec python-pretend.spec python-progress.spec python-pvc.spec python-pysb.spec python-pyvirtualize.spec python-qt5.spec python-requests-oauthlib.spec python-sphinx-bootstrap-theme.spec python-sphinx_lv2_theme.spec python-stuf.spec python-unidecode.spec python-urlobject.spec python-vevents.spec python-vpoller.spec python-wrapt.spec python-wtforms.spec python-xcffib.spec Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Nest 2021 - any Lenovo questions/topics I should cover?
Hi Mark, On Mon, Jul 19, 2021 at 11:52:59AM -0400, Mark Pearson wrote: > Hi Fedorans > > I'd much rather make sure I'm answering any questions the community has - I > figure that's more interesting than me blathering on. I can't promise to > answer everything, but will do my best. If you send me any questions in the > next few days that would be appreciated. > - can you officially support the new X1 Nano? It's basically a Carbon in a more traveler-friendly frame (13") - will there be an expansion of AMD CPU/GPU beyond the T series? e.g. a P1 AMD or an X1 Carbon/Nano AMD would be great - there's some effort by some Fedora developers to collaborate with Nvidia on e.g. making sure Wayland works better. Given some of the officially supported Lenovo laptops have Nvidia GPUs, how much is Lenovo engaged in that process? Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F35 Change: Use power-profiles-daemon on Workstation (late Self-Contained Change proposal)
On Fri, Jul 23, 2021 at 10:09:20AM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Power_Profiles_Daemon > > == Summary == > We will install power-profiles-daemon in Fedora Workstation and enable > it by default. power-profiles-daemon allows the user to choose between > optimizing for system performance or battery life. > Neal kindly informed me that this was actually built for F34 too, and installing the package is sufficient to get it to show in GNOME Control Center's Power pane. Could this be made explicit in the testing instructions, or is the version in F34 sufficiently different that any feedback from F34 users will likely not be relevant? Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Why so long for EPEL-8?
Hi Ron, On Sat, Jul 17, 2021 at 04:15:05PM -0500, Ron Olson wrote: > Hey all- > > I’m curious as to why submitting a new build to Bodhi takes a week to be > pushed to stable, but two weeks for EPEL-8. Is the presumption that it’s just > that much more time for folks to test and verify? > IIRC this is tabled for discussion in the next EPEL SIG meeting - there's a suggestion to reduce this to one week. Cheers, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: rpmautospec deployment into production
Hi Nils, On Fri, Jul 16, 2021 at 03:19:25PM +0200, Nils Philippsen wrote: > > in order to use rpmautospec features, it needs to be available on the > builder machines (which are F34) and, for local operations, on the > machine running fedpkg or equivalent. I.e. making it available on EL8 > will help people whose work environment is RHEL8 or CentOS 8, it > shouldn't be required to be able to build an EL8 package in our > infrastructure. There seems to be a bug[1] which prevents building EL8 > packages that use %autorelease, %autochangelog, which I'm investigating > right now. Huh, the EPEL8 builders are F34? I just realized. Yeah, fedpkg --release epel8 srpm definitely behaved differently on F34 (where the macros are available) and on EPEL8 (not on my EL8 machine now so can't get the exact message, but IIRC it failed saying the changelog was invalid). > > I'd be happy to be able to offer rpmautospec client-side on EL8, too, > but as you found out in [2], this needs a newer pygit2 version than > what is available there. > pygit2 is maintained in EPEL, so there's a possibility of just upgrading it there; I'll have to check if it might break any dependencies though. Would you happen to know what is the minimum pygit2 version that would work for rpmautospec? Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Non-responsive maintainer check for lotharlutz (Markus Mayer)
Does anyone know how to contact Markus? non-responsive tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1982444 He's not responded to PRs on his Phoronix package for 4 months: https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-requests and has not responded to a PR for his other package: https://src.fedoraproject.org/rpms/jimtcl/pull-request/1 or to bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1372986 Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: rpmautospec deployment into production
On Fri, Jun 18, 2021 at 05:30:28PM +0200, Nils Philippsen wrote: > Hi everybody, > > rpmautospec[1] is now deployed on the Koji builders. It took a little > longer than expected, but went smoothly otherwise—at most, you should > have noticed any currently running builds of yours being restarted > when we restarted the kojid processes. > > We invite you to use automatic releases and changelogs in your RPM > packages from now on, refer to [2] for details. Please hit us up on > #fedora-apps (on Libera.chat) if you have questions. If you encounter > any issues, please file them in the project tracker[3]. > Now that this is in the Koji builders... would this be sufficient to have it enabled for EPEL8 specs as well? - branch and build python-rpmautospec for EPEL8 - add Requires: rpmautospec-rpm-macros to epel-rpm-macros in EPEL8 Given that EPEL8 will be around for a while, it sounds like it would be of benefits if we can keep the same spec between Rawhide and it. e.g. python-TestSlide now uses rpmautospec in the Rawhide branch, and so any update in EPEL8 will have to diverge. cc:ing the EPEL devel list so we can discuss if we want to do this Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Retiring python-cliapp and python-coverage-test-runner
Hi all, I'm retiring these two packages - python-cliapp - python-coverage-test-runner Upstream has been dead for three years; they were part of Lars Wirzenius' Obnam backup tool and were meant to be retired with the rest of the stack, and have no other dependent packages. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Announcing fmt library soversion bump
On Mon, Jul 05, 2021 at 08:19:11AM -0500, Richard Shaw wrote: > folly failed: > > /usr/bin/ld: ../../../libfolly.so.2021.06.07.00: undefined reference > to `typeinfo for snappy::Source' > collect2: error: ld returned 1 exit status > > I verified that "-lsnappy" is in the command line so not sure what's going > on there, but it doesn't look fmt related. > > https://kojipkgs.fedoraproject.org//work/tasks/5080/71345080/build.log > Yeah, folly builds are currently broken, I need to find time to fix them. It's indeed related to snappy, and seems to be related to changes in the way the new snappy release is built: https://github.com/facebook/folly/issues/1583 https://github.com/Homebrew/homebrew-core/pull/76686 Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Tue, Jun 29, 2021 at 04:21:03PM -0500, Michael Catanzaro wrote: > On Tue, Jun 29 2021 at 11:05:26 PM +0200, Dan Čermák > wrote: > > Thanks a lot for this Michel! > > Yes, this will reduce packager pain and suffering. Nice! > You're welcome :) If affected package owners want to help, I'm happy to add them as Change owners too. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Packages that failed to build with Python 3.10 (and what to do)
On Tue, Jun 08, 2021 at 05:38:27PM -0700, Michel Alexandre Salim via devel wrote: > Hi, > > On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote: > > Hello. > > > > As you might already know, we have recently merged in the Python 3.10 side > > tag to Rawhide, despite several builds not succeeding. We always aim for > > some compromise between having the side tag open for too long and having > > too many failures. > > > > https://fedoraproject.org/wiki/Changes/Python3.10 > > > > For some reason, `mock -r fedora-rawhide-x86_64 install python3` is > still pulling in python3-3.9.5-2.fc35.x86_64 > > This makes testing any fix rather difficult, as it will pass locally and > then fail when doing a Koji (scratch) build. > > e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2 > For future reference, `mock --enablerepo=local` does the trick. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Packages that failed to build with Python 3.10 (and what to do)
Hi, On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote: > Hello. > > As you might already know, we have recently merged in the Python 3.10 side > tag to Rawhide, despite several builds not succeeding. We always aim for > some compromise between having the side tag open for too long and having > too many failures. > > https://fedoraproject.org/wiki/Changes/Python3.10 > For some reason, `mock -r fedora-rawhide-x86_64 install python3` is still pulling in python3-3.9.5-2.fc35.x86_64 This makes testing any fix rather difficult, as it will pass locally and then fail when doing a Koji (scratch) build. e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2 Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: older than 30 days and empty side tag clean up
On Fri, Jun 04, 2021 at 09:46:00PM +0200, Fabio Valentini wrote: > On Fri, Jun 4, 2021 at 8:58 PM Kevin Fenzi wrote: > > > > On Fri, Jun 04, 2021 at 01:07:39PM -0500, Richard Shaw wrote: > > > On Fri, Jun 4, 2021 at 12:26 PM Kevin Fenzi wrote: > > > > > > > Greetings. > > > > > > > > Release engineering has just enabled a cron job to remove koji side tags > > > > that are older than 30 days or have no builds tagged into them. > > > > > > > > > > It would be nice if they automatically deleted themselves after being used > > > in a Bodhi update. > > > > They are supposed to be. koji has: > > remove_empty = on > > which is supposed to delete sidetags that are empty. > > I'm not sure why thats not working, need to file a issue on it... > > > > That only handles the empty case tho, not the old. > > > > > > > > Can they be deleted immediately or do we need to wait until the update > > > goes > > > stable? > > > > Should be able to delete them right after the update appears. > > Well, there are two different cases here, aren't there? > > For side tags created for rawhide, they are - in my experience - > automatically deleted by bodhi once the update goes to stable, shortly > after it is created. > > For those created for stable releases, I think it makes sense to keep > them around until the update is pushed to stable, too - otherwise you > won't be able to edit the update at all. It looks like the bug that > bodhi didn't delete those side tags after the update is pushed to > stable has been fixed? At least, all my > side-tags-for-stable-release-updates-that-are-now-stable are gone. > Is there a race condition here? If e.g. the maintainer takes some time to get a complicated set of packages all built, and the updates get published to Bodhi on day 25 ... by the time they get auto-pushed to stable it will be day 32 or 33. Perhaps side tags associated with an in-progress update should be excluded. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Packages that failed to build with Python 3.10 (and what to do)
On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote: > Hello. > > As you might already know, we have recently merged in the Python 3.10 side > tag to Rawhide, despite several builds not succeeding. We always aim for > some compromise between having the side tag open for too long and having > too many failures. > > https://fedoraproject.org/wiki/Changes/Python3.10 > ... > fbthrift dcavalca filbranden salimma > follydcavalca filbranden salimma > watchman dcavalca filbranden salimma > These are all related; I'll try to get them fixed. There's a known issue with fbthrift's use of Cython that has been affecting rebuilds for the past few weeks, so now is as good a time as any. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Mon, 2021-05-31 at 15:19 +0200, Peter Boy wrote: > > > > Am 28.05.2021 um 23:08 schrieb Chris Murphy < > > li...@colorremedies.com>: > > > > > …… > > > > All I mean by this is to push back on the idea that the proposal > > for > > Cloud translates into delaying the decision for Server by 5 or 10 > > years. Not that Server folks should escalate their discussion. > > What I originally meant was the idea to discuss / explore > opportunities to coordinate or join the efforts of Server WG and > Cloud WG and to better aline both. Until that happens (and if the Server WG cares about this maybe that should be formally proposed to the Cloud WG?) - it probably does not make sense to expect that Cloud development be held back by anything the Server WG might want to do. > > But that idea seems to me got silently out of attention over time. We > discussed that an the beginning of March, Server WG picked it up > again at the end of March, and there was a brief mention in Cloud WG > in early April. Since then there has been silence. > Do you have a reference for that? Would love to follow that discussion > > > I see the invigorating effect of an adversarial process. However, I > worry that the long-term programmatic aspects will be neglected. And > it emphasizes very much the differentiating and the separating. > That’s fine in a legal process, but not in a community process. > Could you clarify what you mean here? There's a lot of open source communities that develop over time using something similar to the Fedora Change Process. e.g. Python with PEP, Rust with RFC and MCP (Major Change Proposals), even Swift with Evolutions. > And part of such a programmatic discussion would also be the > exploration of common features of server and cloud, of possible > adaptations and synergy effects, which was discussed at the beginning > of the year and planned after Dusty's return. All that is gone now as > a result of that action, virtually in an "overnight coup d'état". And > this was (and is) my argument, not various single technical > properties, advantages or disadvantages of BTRFS. And that is what I > regret. > Such a high level conversation would be nice, but again, until that happens (on devel/server/cloud mailing lists), and there's a consensus about how Server and Cloud would work together going forward, how is a Change Proposal targeted at Cloud usage after months of conversation an "overnight coup d'état"? Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
