Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Kamil Dudka]

On Saturday, June 20, 2020 12:17:26 AM CEST Tomasz Kłoczko wrote:
> All parallel build issues should be treated *as critical bugs*
>  which should be *ASAP fixed*.
> 
> kloczek

Seriously, are you saying that bugs causing slower build are as important
as bugs causing data lost or security vulnerabilities at run time?

If they are so important for you, please help us to get them fixed!

I tried to parallelize the build of nss and failed:

https://src.fedoraproject.org/rpms/nss/c/6e689ce0
https://src.fedoraproject.org/rpms/nss/c/3c27dc24

I would really appreciate your help on this.

Kamil

___
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

Re: Orphaned 215 packages

[Miro Hrončok]

On 20. 06. 20 3:11, Stuart D Gathman wrote:

On Thu, 18 Jun 2020, Stephen Gallagher wrote:


Stewardship SIG guy speaking :)

If you have a limited set of packages that you want to keep working,
e.g. to keep a minimal environment available to build other NodeJS rpm
packages in fedora, then that's exactly what the Stewardship SIG was
originally intended to to, albeit for a limited time only. We also
have some tooling to check leaf package status and analyze dependency
trees, which would also help here.


I have some packages depending on indirectly on nodejs things being
retired.  How do I find out which ones I need to save?


Try https://churchyard.fedorapeople.org/orphans.txt

Search for your FAS username to get the list and also the dependency chain.

(The data might be a bit outdated, see modification time of the file.)

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Dan Čermák]

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
>
> == Summary ==
> This change will update all spec files in Fedora that use make and replace
> the make invocations with either the %make_build or %make_install macros.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email: 
>
>
> == Detailed Description ==
>
> The goal of this change is to standardize the usage of make in Fedora.  All
> make invocations in spec files that don't use the install target will be
> modified to use the %make_build macro, and all make invocations that use
> the install target will be updated to use the %make_install macro.  Any
> additional arguments to make that are not included in either the
> %make_build and %make_install will be preserved.
>
> The %make_build macro enables parallel make builds using the -j option.  In
> case a package does not build correctly with parallel make, then parallel
> make will be disabled for that package by redefining the %_smp_mflags macro
> like this:
>
>   %global _smp_mflags -j1
>
> All changes will be submitted to dist-git repositories via pull requests.
> Pull requests will be merged after 1 week if there are no objections or
> earlier if approved by the package maintainers.
>
> A script will be used to apply the necessary changes to the spec files, and
> the result will be manually inspected before being merged.
>
> All packages updated by this change request will be rebuilt after the spec
> file changes are merged.
>
> Some packages already use the %make_build and %make_install macros.  These
> packages will be left unchanged.
>
> == Benefit to Fedora ==
> * Reduced build times: Using the %make_build macros enables parallel make
> builds which will reduce build times for Fedora packages.
>
> * This will make it easier to enforce consistent build flag usage across
> all of Fedora.
>
> == Scope ==
> * Proposal owners: Update spec files and submit pull requests and do new
> package builds.  Optional: Merge pull requests (Proposal Owner would need
> to request to be added to provenpackagers group)
>
> * Other developers: Package owners may merge pull requests and submit new
> builds if they want, but this is not required for them.  A member of the
> provenpackagers group will be needed to merge pull requests.
> * Release engineering: [https://pagure.io/releng/issues/9533 #9533]
>
> * Policies and guidelines: Package guidelines already specify that packages
> should use these macros when possible.  Documentation will be updated to
> clarify that %make_build should be used for all make invocations (besides
> make install), and also with instructions for packages that fail to build
> with parallel make.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> No impact.
>
> == How To Test ==
> End-users will not notice any changes.
>
> == Dependencies ==
> No real dependencies, each package can be updated independently.
>
> == Contingency Plan ==
> * Contingency mechanism: None.  If not all packages are updated in time,
> then the work can continue into the next release.
> * Contingency deadline: All work will be done in the rawhide branch, and
> will not be backported into the f33 branch once it is created, so whatever
> gets done before the branch date will make it into the release.
> * Blocks release? No
>
> == Documentation ==
> The packaging guidelines will be updated as described in the Scope Section.
>
>
>
> -- 
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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
___
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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Dan Čermák]

Sorry about the empty email, I've hit send too fast…

Anyway, on the topic of parallel builds: what is everyone's opinion on
adding the %limit_build macro from openSUSE (see:
https://build.opensuse.org/package/view_file/network:chromium/memory-constraints/memory-constraints.macros?expand=1)?

tl;dr; %limit_build -m 1500 will set the number of parallel processes so
that if all of them consume 1500 MB of RAM at most, that they will not
OOM your worker (especially handy on workers with many cores, but not
much RAM).


Cheers,

Dan

Dan Čermák  writes:

> Ben Cotton  writes:
>
>> https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
>>
>> == Summary ==
>> This change will update all spec files in Fedora that use make and replace
>> the make invocations with either the %make_build or %make_install macros.
>>
>> == Owner ==
>> * Name: [[User:tstellar| Tom Stellard]]
>> * Email: 
>>
>>
>> == Detailed Description ==
>>
>> The goal of this change is to standardize the usage of make in Fedora.  All
>> make invocations in spec files that don't use the install target will be
>> modified to use the %make_build macro, and all make invocations that use
>> the install target will be updated to use the %make_install macro.  Any
>> additional arguments to make that are not included in either the
>> %make_build and %make_install will be preserved.
>>
>> The %make_build macro enables parallel make builds using the -j option.  In
>> case a package does not build correctly with parallel make, then parallel
>> make will be disabled for that package by redefining the %_smp_mflags macro
>> like this:
>>
>>   %global _smp_mflags -j1
>>
>> All changes will be submitted to dist-git repositories via pull requests.
>> Pull requests will be merged after 1 week if there are no objections or
>> earlier if approved by the package maintainers.
>>
>> A script will be used to apply the necessary changes to the spec files, and
>> the result will be manually inspected before being merged.
>>
>> All packages updated by this change request will be rebuilt after the spec
>> file changes are merged.
>>
>> Some packages already use the %make_build and %make_install macros.  These
>> packages will be left unchanged.
>>
>> == Benefit to Fedora ==
>> * Reduced build times: Using the %make_build macros enables parallel make
>> builds which will reduce build times for Fedora packages.
>>
>> * This will make it easier to enforce consistent build flag usage across
>> all of Fedora.
>>
>> == Scope ==
>> * Proposal owners: Update spec files and submit pull requests and do new
>> package builds.  Optional: Merge pull requests (Proposal Owner would need
>> to request to be added to provenpackagers group)
>>
>> * Other developers: Package owners may merge pull requests and submit new
>> builds if they want, but this is not required for them.  A member of the
>> provenpackagers group will be needed to merge pull requests.
>> * Release engineering: [https://pagure.io/releng/issues/9533 #9533]
>>
>> * Policies and guidelines: Package guidelines already specify that packages
>> should use these macros when possible.  Documentation will be updated to
>> clarify that %make_build should be used for all make invocations (besides
>> make install), and also with instructions for packages that fail to build
>> with parallel make.
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> No impact.
>>
>> == How To Test ==
>> End-users will not notice any changes.
>>
>> == Dependencies ==
>> No real dependencies, each package can be updated independently.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: None.  If not all packages are updated in time,
>> then the work can continue into the next release.
>> * Contingency deadline: All work will be done in the rawhide branch, and
>> will not be backported into the f33 branch once it is created, so whatever
>> gets done before the branch date will make it into the release.
>> * Blocks release? No
>>
>> == Documentation ==
>> The packaging guidelines will be updated as described in the Scope Section.
>>
>>
>>
>> -- 
>> Ben Cotton
>> He / Him / His
>> Senior Program Manager, Fedora & CentOS Stream
>> Red Hat
>> TZ=America/Indiana/Indianapolis
>> ___
>> 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


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-condu

Re: RHEL 9 and modularity

[Dan Čermák]

Josh Boyer  writes:

> On Fri, Jun 19, 2020 at 2:54 PM David Cantrell  wrote:
>>
>> On Thu, Jun 18, 2020 at 08:44:39AM -0400, Josh Boyer wrote:
>> >Hopefully that provides some context and helps FESCo and the wider
>> >community understand where Red Hat is headed with modularity on the
>> >Enterprise side.
>>
>> Around the idea and concept of modularity... what are the benefits to Fedora,
>> Fedora developers, and Fedora contributors?  Through the various discussions
>> on modularity, nothing solid in this regard has been presented.  If I am
>> Fedora contributor now, what can modularity do for me?
>>
>> Most of the remainder of this thread talks about the problems with the
>> implementation as it exists today and problems with other known options.
>> Putting that aside for now, why should Fedora contributors care about
>> modularity?
>>
>> Put another way, what does the developer experience look like for modularity?
>
> These are good questions, but I feel like there has been about 2+
> years of discussion and debate about what Fedora could get out of
> modularity.

Well, a short tl;dr; would certainly help, as I must admit that even
after 2+ years of discussion I see very little incentive to modularize
any of my packages.

I see benefits of modularity for CentOS/RHEL, but not so clearly for
Fedora (except for more special cases like sway, where we have the
quickly evolving wlroots library and can thus deliver an up to date sway
even for older Fedora releases).

> I'm not sure I have anything to offer that is directly
> new or better.  I do think that ELN presents a new opportunity for
> those that have already found value in the Fedora community to use and
> improve it there in the absence of widespread Fedora adoption.
> Perhaps that would allow a place for the ideas to grow and could prove
> to be illustrative.
>
> At any rate, my goal isn't to evangelize or convert Fedora to suddenly
> embrace modularity wholescale.  I am simply offering clarity on the
> plans for RHEL 9 with this technology.
>
> josh
> ___
> 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


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

Re: Highlights from the latest Copr release 2020-06-10

[Andy Mender]

> - Copr project "runtime" dependencies were implemented.  Newly you can
>   specify set of repositories your project depends on. Such repositories
>   will be installed together with the copr project repo file (e.g., by
>   'dnf copr enable YOU/YOUR_PROEJCT').  Those repositories can be other
>   project in Copr or some 3rd party repository.  This is very similar to
>   build-time dependencies implemented long time ago.  Take a look at
>   blog post:
>
> https://fedora-copr.github.io/posts/runtime-dependencies


 This is fantastic news! In one of my COPR projects the cross-dependency
prevented me from being able to host the project properly.

- Cancel build feature was fixed, and the "cancel" request should reliably
>   release all occupied builder machines (allowing them to be re-used, or
>   terminated).
>
> Also this. Thank you!
___
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

Re: RHEL 9 and modularity

[Neal Gompa]

On Sat, Jun 20, 2020 at 5:31 AM Dan Čermák
 wrote:
>
> Josh Boyer  writes:
>
> > On Fri, Jun 19, 2020 at 2:54 PM David Cantrell  wrote:
> >>
> >> On Thu, Jun 18, 2020 at 08:44:39AM -0400, Josh Boyer wrote:
> >> >Hopefully that provides some context and helps FESCo and the wider
> >> >community understand where Red Hat is headed with modularity on the
> >> >Enterprise side.
> >>
> >> Around the idea and concept of modularity... what are the benefits to 
> >> Fedora,
> >> Fedora developers, and Fedora contributors?  Through the various 
> >> discussions
> >> on modularity, nothing solid in this regard has been presented.  If I am
> >> Fedora contributor now, what can modularity do for me?
> >>
> >> Most of the remainder of this thread talks about the problems with the
> >> implementation as it exists today and problems with other known options.
> >> Putting that aside for now, why should Fedora contributors care about
> >> modularity?
> >>
> >> Put another way, what does the developer experience look like for 
> >> modularity?
> >
> > These are good questions, but I feel like there has been about 2+
> > years of discussion and debate about what Fedora could get out of
> > modularity.
>
> Well, a short tl;dr; would certainly help, as I must admit that even
> after 2+ years of discussion I see very little incentive to modularize
> any of my packages.
>
> I see benefits of modularity for CentOS/RHEL, but not so clearly for
> Fedora (except for more special cases like sway, where we have the
> quickly evolving wlroots library and can thus deliver an up to date sway
> even for older Fedora releases).
>

TL;DR benefits of modularity for Fedora:

* Automating build chains for producing artifacts
* Straightforward mechanism of producing non-rpm artifacts using our
existing tooling (modules -> flatpaks/containers/etc.)
* Path to provide alternative versions of stacks that don't natively
multiversion (Nodejs, Perl, PHP, etc.)




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Andy Mender]

On Sat, 20 Jun 2020 at 00:38, Miro Hrončok  wrote:

> On 19. 06. 20 23:11, Ben Cotton wrote:
> > All make invocations in spec files that don't use the install target
> will be
> > modified to use the %make_build macro
>
> Many Python packages build Sphinx documentation with variant of "make
> html".
> Such invocation will always be just 1 job. Hence there is no benefit of
> parallel
> make. Replacing it with %make_build will only make it harder to read.
>
> Can we exclude such cases? Or do we want all make invocations to be
> mecronized,
> even if there is no benefit?
>

The way I understand it is that %make_build would be a replacement for the
"make all" target with N jobs, which is called by default when you just run
"make". That would be the all-in-1 scenario when you want to build the main
binaries, docs and examples. If there is only 1 target (html) and you run
"make" with N jobs, there is no downside, because only that single target
gets picked up.

I really like the proposal and kind of sort of agree with Tomasz that if a
build requires -j1 explicitly and fails with -jN, it means the target
dependency tree was not defined properly and should be fixed. The only time
I ever run "make" with -j1 is when debugging to get a clean, sequential log
output. So the way one can handle target resolution issues is with the
proposed %global _smp_mflags -j1 or with a unified patch + submission to
upstream to fix the bug.

~Andy
___
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

Re: Modules building for Fedora 30

[Stephen John Smoogen]

On Fri, 19 Jun 2020 at 23:16, Orion Poplawski  wrote:
>
> I just noticed that my openmpi module build is building for Fedora 30.
> This seems like a mistake.  Where do I report that?
>

I think it should be reported here: https://pagure.io/releng/issues



> --
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
>
> ___
> 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



-- 
Stephen J Smoogen.
___
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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Miro Hrončok]

On 20. 06. 20 14:47, Andy Mender wrote:
On Sat, 20 Jun 2020 at 00:38, Miro Hrončok > wrote:


On 19. 06. 20 23:11, Ben Cotton wrote:
 > All make invocations in spec files that don't use the install target 
will be
 > modified to use the %make_build macro

Many Python packages build Sphinx documentation with variant of "make html".
Such invocation will always be just 1 job. Hence there is no benefit of
parallel
make. Replacing it with %make_build will only make it harder to read.

Can we exclude such cases? Or do we want all make invocations to be 
mecronized,
even if there is no benefit?


The way I understand it is that %make_build would be a replacement for the "make 
all" target with N jobs, which is called by default when you just run "make". 


The proposal says all make invocations.

That would be the all-in-1 scenario when you want to build the main binaries, 
docs and examples. If there is only 1 target (html) and you run "make" with N 
jobs, there is no downside, because only that single target gets picked up.


No downside when building, but downside when reading the spec file.

I really like the proposal and kind of sort of agree with Tomasz that if a build 
requires -j1 explicitly and fails with -jN, it means the target dependency tree 
was not defined properly and should be fixed.


That is not the case here.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Re: libgps soname bump (gpsd-3.20)

[Adam Williamson]

On Thu, 2020-06-18 at 20:32 +0200, Björn 'besser82' Esser wrote:
> Am Donnerstag, den 18.06.2020, 16:34 +0200 schrieb Miroslav Lichvar:
> > A new version of gpsd is ready to be build in rawhide. This is a
> > second attempt. It now bumps the libgps soname. Per repoquery the
> > following packages have a dependency on libgps and will need a
> > rebuild:
> > 
> > collectd
> > direwolf
> > foxtrotgps
> > marble
> > plasma-workspace
> > qlandkartegt
> > vfrnav
> > viking
> > 
> > Some packages already carry a patch for the new libgps API. Some
> > will
> > need to be fixed. I've uploaded the patches here:
> > 
> > https://mlichvar.fedorapeople.org/tmp/gpsd
> > 
> > vfrnav doesn't build for me due to a C++ issue, so I'm not sure if
> > the
> > gps fix is complete.
> > 
> > If a proven packager could add/merge the patches and rebuild all
> > the packages, please me know. Otherwise, I'll rebuild gpsd
> > sometimes
> > next week and let the maintainers fix their packages.
> 
> 
> I've built gpsd-3.20-1, and rebuilt all listed packages.  The
> contents
> of the side-tag has been filed as an update [1].
> 
> 
> The following packages are FTBFS, but not related to the gpsd update:
> 
>   * plasma-workspace - missing dependencies
>   * vfrnav - looks like some problems with recent Boost
> 
> I leave it up to the corresponding maintainers to fix them.

Please never do this again, because you have now broken Rawhide.

plasma-workspace is a key component of KDE, and KDE is a release-
blocking desktop. This means the Rawhide compose fails if the KDE live
build fails. The KDE live build now fails and we cannot fix this
without fixing the plasma-workspace FTBFS.

In future please do not push an soname bump if it is known to break a
critical package like plasma-workspace.

Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: libgps soname bump (gpsd-3.20)

[Adam Williamson]

On Sat, 2020-06-20 at 08:30 -0700, Adam Williamson wrote:
> > 
> > The following packages are FTBFS, but not related to the gpsd
> > update:
> > 
> >   * plasma-workspace - missing dependencies
> >   * vfrnav - looks like some problems with recent Boost
> > 
> > I leave it up to the corresponding maintainers to fix them.
> 
> Please never do this again, because you have now broken Rawhide.
> 
> plasma-workspace is a key component of KDE, and KDE is a release-
> blocking desktop. This means the Rawhide compose fails if the KDE
> live
> build fails. The KDE live build now fails and we cannot fix this
> without fixing the plasma-workspace FTBFS.
> 
> In future please do not push an soname bump if it is known to break a
> critical package like plasma-workspace.

So the problem with plasma-workspace is that most of Plasma is bumped
to 5.19 in dist-git, but pushing 5.19 actually got stuck halfway
through and we wound up untagging all 5.19 builds so what's tagged into
Rawhide is 5.18. Most Plasma packages won't build from the current
state of dist-git HEAD.

I reverted plasma-workspace to the state of the build that's currently
tagged (5.18.5-1.fc32) and pushed a bump-and-rebuild, hopefully it'll
go through this time. I also poked the KDE team to ask them to please
complete the 5.19 bump.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: Modules building for Fedora 30

[Kevin Fenzi]

On Sat, Jun 20, 2020 at 09:45:15AM -0400, Stephen John Smoogen wrote:
> On Fri, 19 Jun 2020 at 23:16, Orion Poplawski  wrote:
> >
> > I just noticed that my openmpi module build is building for Fedora 30.
> > This seems like a mistake.  Where do I report that?
> >
> 
> I think it should be reported here: https://pagure.io/releng/issues

Yeah, thats fine, or infrastructure. 

I'm not sure however where that is configured, so it might be some
digging before we can fix it. None of: '30' 'fedora-30' 'platform:f30' 
appear in the mbs configuration. ;( 

kevin


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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jun 19, 2020 at 05:11:43PM -0400, Ben Cotton wrote:
> The %make_build macro enables parallel make builds using the -j option.  In
> case a package does not build correctly with parallel make, then parallel
> make will be disabled for that package by redefining the %_smp_mflags macro
> like this:
> 
>   %global _smp_mflags -j1

That is rather unwiely, in particular because it's quite common for
just *some* make invocations to fail in parallel mode. (E.g. the main
build works, but doc build fails, or install, etc.)

Why not specify the override for the individual invocation:
%make_build -j1
%make_install -j1
%make_build -C docs -j1

Zbyszek
___
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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Neal Gompa]

On Sat, Jun 20, 2020 at 2:16 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Jun 19, 2020 at 05:11:43PM -0400, Ben Cotton wrote:
> > The %make_build macro enables parallel make builds using the -j option.  In
> > case a package does not build correctly with parallel make, then parallel
> > make will be disabled for that package by redefining the %_smp_mflags macro
> > like this:
> >
> >   %global _smp_mflags -j1
>
> That is rather unwiely, in particular because it's quite common for
> just *some* make invocations to fail in parallel mode. (E.g. the main
> build works, but doc build fails, or install, etc.)
>
> Why not specify the override for the individual invocation:
> %make_build -j1
> %make_install -j1
> %make_build -C docs -j1
>

I think I'd be more comfortable with making all "make %{?_smp_mflags}"
calls switch to "%make_build" and leaving the rest alone.

As for "make DESTDIR=%{buildroot} install" to "%make_install", I'm fine with it.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: Orphaned 215 packages

[Sérgio Basto]

On Thu, 2020-06-18 at 15:09 -0400, Stephen Gallagher wrote:
> On Thu, Jun 18, 2020 at 12:51 PM Ben Rosser 
> wrote:
> > On Wed, Jun 17, 2020 at 12:50 PM Fabio Valentini <
> > decatho...@gmail.com> wrote:
> > > On Wed, Jun 17, 2020 at 6:30 PM Ben Rosser 
> > > wrote:
> > > > On Tue, Jun 16, 2020 at 5:38 PM Jared K. Smith <
> > > > jsm...@fedoraproject.org> wrote:
> > > > > On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser <
> > > > > rosser@gmail.com> wrote:
> > > > > > So... this is a lot of node.js packages, and I haven't
> > > > > > really seen any discussion of this on the lists. And at
> > > > > > least some of these are possibly important for other nodejs
> > > > > > packages-- notably "mocha", which I suspect is used in at
> > > > > > least some packages to run unit tests (at the very least,
> > > > > > several of my nodejs packages use it to run unit tests...).
> > > > > 
> > > > > Indeed... I'd hate to see mocha disappear.  That being said,
> > > > > there's a bunch of these other packages that can probably
> > > > > safely be retired -- I pulled in a couple hundred NodeJS
> > > > > packages in my hard-headed attempt to get NodeRED into Fedora
> > > > > for the IoT team a couple of years ago, but got bogged down
> > > > > in dependency nightmares and ultimately gave up.  Since then,
> > > > > I've been busy with my job and grad school to really spend a
> > > > > lot of time worrying about NodeJS packages in Fedora, since
> > > > > I'm not a NodeJS developer.  That being said, if there are
> > > > > packages like mocha that really need to be maintained to keep
> > > > > the NodeJS ecosystem working in Fedora, I could probably be
> > > > > persuaded to pick up a few more packages.
> > > > > 
> > > > > -Jared
> > > > 
> > > > Hi Jared,
> > > > 
> > > > That makes sense to me. Maybe the priority should be trying to
> > > > keep
> > > > mocha alive, and eventually figuring out how to update it? The
> > > > current
> > > > dependencies, according to repoqery, are as follows:
> > > > 
> > > > (npm(commander) >= 2.2.0 with npm(commander) < 3)
> > > > (npm(debug) >= 2.2.0 with npm(debug) < 3)
> > > > (npm(diff) >= 1.0.8 with npm(diff) < 2)
> > > > (npm(escape-string-regexp) >= 1.0.2 with npm(escape-string-
> > > > regexp) < 2)
> > > > (npm(glob) >= 6.0.3 with npm(glob) < 7)
> > > > (npm(growl) >= 1.7.0 with npm(growl) < 2)
> > > > (npm(jade) >= 1.3.1 with npm(jade) < 2)
> > > > (npm(mkdirp) >= 0.5.0 with npm(mkdirp) < 0.6)
> > > > /usr/bin/env
> > > > nodejs(engine) >= 0.8.0
> > > > npm(supports-color)
> > > > 
> > > > I haven't looked further to see what the dependency tree is
> > > > like for
> > > > each of these, but commander, debug, diff, glob, and growl are
> > > > all
> > > > currently orphaned.
> > > 
> > > Hi,
> > > 
> > > Stewardship SIG guy speaking :)
> > > 
> > > If you have a limited set of packages that you want to keep
> > > working,
> > > e.g. to keep a minimal environment available to build other
> > > NodeJS rpm
> > > packages in fedora, then that's exactly what the Stewardship SIG
> > > was
> > > originally intended to to, albeit for a limited time only. We
> > > also
> > > have some tooling to check leaf package status and analyze
> > > dependency
> > > trees, which would also help here.
> > > 
> > > However! I've tried to shepherd our Java packages into the
> > > "refounded"
> > > Java SIG for a few weeks, but so far, I haven't had any success,
> > > with
> > > no contributions from people other than me in the past 2-3 weeks
> > > ...
> > > and I'd rather not try to start adding new packages into the
> > > Stewardship SIG umbrella without also getting help from packagers
> > > (both packagers familiar with NodeJS to look after the NodeJS
> > > stack,
> > > and packagers familiar with Java to finalize the move of Java
> > > packages
> > > into the new Java SIG).
> > 
> > Hi Fabio,
> > 
> > I'm not sure how much time I'll be able to put in, but I'd be very
> > happy to (help) work on this, either as part of the Stewardship or
> > Nodejs SIGs, or both. Hopefully others interested in the nodejs
> > ecosystem (Sérgio and Jared, perhaps?) would be willing to consider
> > helping too.
> > 
> > The Nodejs SIG does have ACLs on (almost?) all of these packages,
> > and
> > I know there are at least a few active packagers there, so
> > hopefully
> > they would be willing to help as well. I think the immediate
> > problem
> > is figuring out what in this large stack of nodejs packages is
> > actually useful (and stopping them from being retired in a week and
> > a
> > half), so being able to use the tooling you mentioned would be very
> > helpful, I think. Then we'd need to ultimately find new
> > points-of-contact for the useful ones (while allowing the non-
> > useful
> > ones to be retired); in the long term, I'd be willing to pick up
> > some
> > of those (hopefully not all, but who knows).
> > 
> > How does one go about joining the Stewardship SIG?
> 
> The Node.js SIG is very loosely organized

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Björn Persson]

Miro Hrončok wrote:
> On 19. 06. 20 23:11, Ben Cotton wrote:
> > All make invocations in spec files that don't use the install target will 
> > be 
> > modified to use the %make_build macro  
> 
> Many Python packages build Sphinx documentation with variant of "make html". 
> Such invocation will always be just 1 job. Hence there is no benefit of 
> parallel 
> make.

That's also the case in several Ada packages, where the makefile just
assembles the command line for a single invocation of GPRbuild, and
parallel compilation is handled by GPRbuild. I expect that there are
many other more or less special cases.

> Replacing it with %make_build will only make it harder to read.

Especially in cases like "make check", where the purpose isn't to build
anything but to run a testsuite. The word "make" is already less than
ideal in those cases, and replacing it with the less well-known
"make_build" will make it more confusing.

> Can we exclude such cases? Or do we want all make invocations to be 
> mecronized, 
> even if there is no benefit?

So I too want that question answered.


Also: Is it set in stone that "make_build" means "make in parallel" and
nothing else? If so, why isn't the macro called "parallel_make"?

Or is it the case that "make_build" means "the typical make command to
use in a build stage", and a future version of the macro may include
other parameters that are considered useful in a build stage but may
not be appropriate for other use cases? In that case the macro should
only be applied in the %build section, and any make invocation that
looks less than typical should be left alone.

Björn Persson


pgpiEkUcHlE5Z.pgp
Description: OpenPGP digital signatur
___
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

Re: RHEL 9 and modularity

[John M. Harris Jr]

On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
> TL;DR benefits of modularity for Fedora:
> 
> * Automating build chains for producing artifacts
> * Straightforward mechanism of producing non-rpm artifacts using our
> existing tooling (modules -> flatpaks/containers/etc.)

Both of these have nothing to do with Modularity, and can be done with 
existing RPMs.

> * Path to provide alternative versions of stacks that don't natively
> multiversion (Nodejs, Perl, PHP, etc.)

Modularity doesn't support installing multiple versions of the same software. 
It's one of the key issues with the tech.

-- 
John M. Harris, Jr.

___
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

Re: RHEL 9 and modularity

[Neal Gompa]

On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr  wrote:
>
> On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
> > TL;DR benefits of modularity for Fedora:
> >
> > * Automating build chains for producing artifacts
> > * Straightforward mechanism of producing non-rpm artifacts using our
> > existing tooling (modules -> flatpaks/containers/etc.)
>
> Both of these have nothing to do with Modularity, and can be done with
> existing RPMs.
>

They have everything to do with Modularity, because that layer is
where that stuff was implemented. Modularity was the result of the
efforts involved with Factory 2.0, which gave us a lot of improvements
in our build infrastructure tooling for the first time since 2007.
Most of that rolled out in 2017, a full ten years after the last
revamp of our infrastructure.

> > * Path to provide alternative versions of stacks that don't natively
> > multiversion (Nodejs, Perl, PHP, etc.)
>
> Modularity doesn't support installing multiple versions of the same software.
> It's one of the key issues with the tech.
>

Modules can be designed to be parallel installable if the underlying
software natively supports that. For example, Python works that way
now, and thus in RHEL there are parallel versions of Python shipped as
modules. It doesn't change the nature of the software.

But it makes it easier to make multiple complete, yet conflicting,
collections of a language stack.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: RHEL 9 and modularity

[John M. Harris Jr]

On Saturday, June 20, 2020 2:40:48 PM MST Neal Gompa wrote:
> On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr 
> wrote:
> >
> >
> > On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
> > 
> > > TL;DR benefits of modularity for Fedora:
> > >
> > >
> > >
> > > * Automating build chains for producing artifacts
> > > * Straightforward mechanism of producing non-rpm artifacts using our
> > > existing tooling (modules -> flatpaks/containers/etc.)
> >
> >
> >
> > Both of these have nothing to do with Modularity, and can be done with
> > existing RPMs.
> >
> >
> 
> 
> They have everything to do with Modularity, because that layer is
> where that stuff was implemented. Modularity was the result of the
> efforts involved with Factory 2.0, which gave us a lot of improvements
> in our build infrastructure tooling for the first time since 2007.
> Most of that rolled out in 2017, a full ten years after the last
> revamp of our infrastructure.

As far as I'm aware, flatpacks can be created without any Modules. Containers 
certainly can, we've been doing that for over a decade now without them.

> > > * Path to provide alternative versions of stacks that don't natively
> > > multiversion (Nodejs, Perl, PHP, etc.)
> >
> >
> >
> > Modularity doesn't support installing multiple versions of the same
> > software. It's one of the key issues with the tech.
> >
> >
> 
> 
> Modules can be designed to be parallel installable if the underlying
> software natively supports that. For example, Python works that way
> now, and thus in RHEL there are parallel versions of Python shipped as
> modules. It doesn't change the nature of the software.
> 
> But it makes it easier to make multiple complete, yet conflicting,
> collections of a language stack.

Where the underlying software already supports it, you don't need Modules to 
do that, just regular old packages. See Python, for example. Modularity is not 
a requirement for that.

-- 
John M. Harris, Jr.

___
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

Re: RHEL 9 and modularity

[Neal Gompa]

On Sat, Jun 20, 2020 at 6:51 PM John M. Harris Jr  wrote:
>
> On Saturday, June 20, 2020 2:40:48 PM MST Neal Gompa wrote:
> > On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr 
> > wrote:
> > >
> > >
> > > On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
> > >
> > > > TL;DR benefits of modularity for Fedora:
> > > >
> > > >
> > > >
> > > > * Automating build chains for producing artifacts
> > > > * Straightforward mechanism of producing non-rpm artifacts using our
> > > > existing tooling (modules -> flatpaks/containers/etc.)
> > >
> > >
> > >
> > > Both of these have nothing to do with Modularity, and can be done with
> > > existing RPMs.
> > >
> > >
> >
> >
> > They have everything to do with Modularity, because that layer is
> > where that stuff was implemented. Modularity was the result of the
> > efforts involved with Factory 2.0, which gave us a lot of improvements
> > in our build infrastructure tooling for the first time since 2007.
> > Most of that rolled out in 2017, a full ten years after the last
> > revamp of our infrastructure.
>
> As far as I'm aware, flatpacks can be created without any Modules. Containers
> certainly can, we've been doing that for over a decade now without them.
>

Yes, they can, but it's a lot more painful to do so. The Modularity
tooling automates reusing the existing RPM packaging we have and
transforms them into building blocks used to produce a Flatpak
application bundle based on the Fedora runtime that people can use
easily on Fedora or any other distribution.

As for containers, the modularity tooling makes it possible to produce
base containers for various language stacks that look and feel like
native stacks provided by Fedora. You've probably never used any of
the RHEL UBI stuff, or any of the language stack containers built on
UBI. Those containers are *fantastic* to work with. My developer
friends find them a literal *joy* to use compared to the alternatives.
I want *that* in Fedora as well, so people can take advantage of the
fresher base and attract more developer-types to our community.

And Modularity makes that stuff possible in a reasonable way.

> > > > * Path to provide alternative versions of stacks that don't natively
> > > > multiversion (Nodejs, Perl, PHP, etc.)
> > >
> > >
> > >
> > > Modularity doesn't support installing multiple versions of the same
> > > software. It's one of the key issues with the tech.
> > >
> > >
> >
> >
> > Modules can be designed to be parallel installable if the underlying
> > software natively supports that. For example, Python works that way
> > now, and thus in RHEL there are parallel versions of Python shipped as
> > modules. It doesn't change the nature of the software.
> >
> > But it makes it easier to make multiple complete, yet conflicting,
> > collections of a language stack.
>
> Where the underlying software already supports it, you don't need Modules to
> do that, just regular old packages. See Python, for example. Modularity is not
> a requirement for that.
>

It is easy without modules for the interpreter, but it's a royal pain
to do it for *everything* (interpreter, language package manager, and
all associated Python modules). Modules provide a straightforward way
to define what that would look like and build that in a repeatable
manner. A Python stack is roughly ~4K source packages, with all kinds
of "fun" ordering requirements. The Modularity tooling provides a way
to do this sort of thing properly. Without Modularity, we've got
*nothing* to do that in a way that's reasonably automated and easy to
maintain.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: RHEL 9 and modularity

[Stephen John Smoogen]

On Sat, 20 Jun 2020 at 17:42, Neal Gompa  wrote:
>
> On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr  
> wrote:
> >
> > On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
> > > TL;DR benefits of modularity for Fedora:
> > >
> > > * Automating build chains for producing artifacts
> > > * Straightforward mechanism of producing non-rpm artifacts using our
> > > existing tooling (modules -> flatpaks/containers/etc.)
> >
> > Both of these have nothing to do with Modularity, and can be done with
> > existing RPMs.
> >
>
> They have everything to do with Modularity, because that layer is
> where that stuff was implemented. Modularity was the result of the
> efforts involved with Factory 2.0, which gave us a lot of improvements
> in our build infrastructure tooling for the first time since 2007.
> Most of that rolled out in 2017, a full ten years after the last
> revamp of our infrastructure.
>

I think that John and others aren't aware of how a module is built
enough to understand what you meant by
* Automating build chains for producing artifacts
compared to how it is done normally.

In normal times, a packager goes through a list of packages, updates
spec files with new tags and rebuilds them one by one as needed..
sometimes multiple times because of bootstrapping or finding out that
the order you tried was wrong. A made up example from my days of doing
this for a different place (this isn't what is needed anymore but long
ago I had something similar):
bison
flex
gcc [options 1]
bison
flex
gcc [options 2]
glibc
bison
flex
gcc

do them in one order and the apps came out working... do them in the
wrong order and it might not. Rust, Java and other language stacks
have similar loops. A packager may have to coordinate with multiple
people to do this several times.

In a module, you write that all down in the manifest with the order
that you want packages built in and if you need to loop through them
with different options. Then MBS does the builds in an automated
fashion and it is repeatable. To me this is the biggest win here as
for various groups of mass-rebuilds it cuts down errors when order
matters and you have to do multiple ones to get from package set A to
package set A+1.

Making it easier to make flatpacks and stuff also is built into the
tools which came with modularity. The tools which were doing it for
the Fedora buildsystem before this  were 'fragile'.

Yes a packager or system administrator can build these things without
the modularity build system but trying to do it in scale in Fedora
ended up needing the tools which came with MBS.


-- 
Stephen J Smoogen.
___
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

Re: RHEL 9 and modularity

[Nico Kadel-Garcia]

On Thu, Jun 18, 2020 at 8:45 AM Josh Boyer  wrote:

Modularity has been an interesting idea on paper, but not worth the
effort. It should not be used for RHEL 9.

> It is always good to push the boundaries and search for better ideas
> and improvements, and that is part of what makes Fedora great.  We are
> doing this in the context of the RHEL 9 release as well, so our near
> term timeline and requirements mean we are working on evolving
> modularity, not a revolution or a replacement.  We are excited by ELN,

Or: you could discard modularity for RHEL 9. My experience with recent
Fedora releases and RHEL 8 has been that it's been destabilizing to
active and to build environments, with no detectable benefit.

Can you, or can anyone else, cite a single issue it has helped with?
Especially one that was not better resolved with other existing
deployment tools, such as /etc/alternatives or version pinning?
___
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

Re: RHEL 9 and modularity

[Neal Gompa]

On Sat, Jun 20, 2020 at 7:40 PM Nico Kadel-Garcia  wrote:
>
> On Thu, Jun 18, 2020 at 8:45 AM Josh Boyer  wrote:
>
> Modularity has been an interesting idea on paper, but not worth the
> effort. It should not be used for RHEL 9.
>

This is the wrong place to try to convince Red Hat otherwise. It's
also not going to happen. And frankly, I wouldn't want to.

> > It is always good to push the boundaries and search for better ideas
> > and improvements, and that is part of what makes Fedora great.  We are
> > doing this in the context of the RHEL 9 release as well, so our near
> > term timeline and requirements mean we are working on evolving
> > modularity, not a revolution or a replacement.  We are excited by ELN,
>
> Or: you could discard modularity for RHEL 9. My experience with recent
> Fedora releases and RHEL 8 has been that it's been destabilizing to
> active and to build environments, with no detectable benefit.
>
> Can you, or can anyone else, cite a single issue it has helped with?
> Especially one that was not better resolved with other existing
> deployment tools, such as /etc/alternatives or version pinning?

Yes, actually. The Nodejs and PHP language stacks, as they are shipped
in RHEL/CentOS 8, are tremendously useful in the current form.

From my perspective, there are two major advantages:

* The language stacks are maintained and operate consistently. What I
mean by this is that each variant of the PHP and Nodejs language
stacks presents the same, consistent interface. I can build on those
interfaces with one version and trivially move forward to the next one
when I'm ready.

* The module stream locking feature is useful in that I can trust that
updates will flow freely for those modules, and I don't have to fiddle
with any fragile configuration in the package manager to keep things
going as I desire. It gives me the necessary control to shift at *my*
pace while still trusting that the whole stack is supported.

Are there problems with it? Absolutely. It was a tremendous effort for
me to bring up modularity support in my internal infrastructure. But
once I got there, I was able to realize these benefits for my own
pipelines. There are still problems, and I've filed bug reports about
them and communicated to the various developers about them, but it's
on a "trending upward" path for me.

And I won't lie and say I don't want improvements. I want to be able
to leverage it more. I want improved packager ergonomics. I want
content reusability (builds across multiple modules to be reusable for
modular content instead of building for each module if the
configuration is effectively the same). And so on.

But I will *not* argue to drop it in RHEL (or even Fedora) because I
think it is useful in a lot of ways and has potential to really make
our lives better.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Kevin Kofler]

Ben Cotton wrote:
> == Summary ==
> This change will update all spec files in Fedora that use make and replace
> the make invocations with either the %make_build or %make_install macros.
> 
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email: 

I am opposed to this change.

Unlike other distros, it has always been Fedora policy to avoid this kind of 
pointless macros and just spell things out, in the name of readability. I 
think that should still be the way to go, also considering that:

> The %make_build macro enables parallel make builds using the -j option. 
> In case a package does not build correctly with parallel make, then
> parallel make will be disabled for that package by redefining the
> %_smp_mflags macro like this:
> 
>   %global _smp_mflags -j1

This does not work when some make targets (typically, the default "all" 
target) support parallel make and others don't.

Additionally, how do you determine that "a package does not build correctly 
with parallel make"? Parallel make failures are race conditions and thus not 
reproducible. The builds can fail or succeed at random. The only safe 
approach is to assume that a package that does not use %{_smp_mflags} at 
this time probably omits it for a reason.

> All changes will be submitted to dist-git repositories via pull requests.
> Pull requests will be merged after 1 week if there are no objections or
> earlier if approved by the package maintainers.

What is the point of making such a purely cosmetic change as a mass change 
to all packages, with the potential of breaking things?

> == Benefit to Fedora ==
> * Reduced build times: Using the %make_build macros enables parallel make
> builds which will reduce build times for Fedora packages.

That is not true. The guidelines and templates clearly specify use of 
%{_smp_mflags}, so IMHO it is safe to assume that those packages that 
actually support parallel build already use %{_smp_mflags} and hence will 
not start building any faster.

As for those packages that do not currently use parallel build, see above: 
you have to assume that they omit it for a reason. It is unsafe to enable it 
behind the maintainer's back (giving them only 1 week to object, if they 
even realize that %make_build invisibly enables %{_smp_mflags} to begin with 
– IMHO, such hidden flags must be considered harmful).

> * This will make it easier to enforce consistent build flag usage across
> all of Fedora.

What kind of build flags? Compiler flags? The valid way to set those depends 
on the build system used. Passing make CFLAGS="…" with no knowledge of what 
the makefile looks like is inherently unsafe: it can override required flags 
set by the build system or a handwritten makefile, it can also end up being 
ignored entirely. Usually, the right way to set flags is before the build 
system or configure script invocation, not in the make step at all. (The 
build system then hardcodes the flags in the makefile, so you do not have to 
pass them again in the make step.)

Kevin Kofler
___
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

Re: RHEL 9 and modularity

[John M. Harris Jr]

On Saturday, June 20, 2020 4:37:06 PM MST Stephen John Smoogen wrote:
> On Sat, 20 Jun 2020 at 17:42, Neal Gompa  wrote:
> 
> >
> >
> > On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr 
> > wrote:
> 
> > >
> > >
> > > On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
> > > 
> > > > TL;DR benefits of modularity for Fedora:
> > > >
> > > >
> > > >
> > > > * Automating build chains for producing artifacts
> > > > * Straightforward mechanism of producing non-rpm artifacts using our
> > > > existing tooling (modules -> flatpaks/containers/etc.)
> > >
> > >
> > >
> > > Both of these have nothing to do with Modularity, and can be done with
> > > existing RPMs.
> > >
> > >
> >
> >
> >
> > They have everything to do with Modularity, because that layer is
> > where that stuff was implemented. Modularity was the result of the
> > efforts involved with Factory 2.0, which gave us a lot of improvements
> > in our build infrastructure tooling for the first time since 2007.
> > Most of that rolled out in 2017, a full ten years after the last
> > revamp of our infrastructure.
> >
> >
> 
> 
> I think that John and others aren't aware of how a module is built
> enough to understand what you meant by
> * Automating build chains for producing artifacts
> compared to how it is done normally.
> 
> In normal times, a packager goes through a list of packages, updates
> spec files with new tags and rebuilds them one by one as needed..
> sometimes multiple times because of bootstrapping or finding out that
> the order you tried was wrong. A made up example from my days of doing
> this for a different place (this isn't what is needed anymore but long
> ago I had something similar):
> bison
> flex
> gcc [options 1]
> bison
> flex
> gcc [options 2]
> glibc
> bison
> flex
> gcc
> 
> do them in one order and the apps came out working... do them in the
> wrong order and it might not. Rust, Java and other language stacks
> have similar loops. A packager may have to coordinate with multiple
> people to do this several times.
> 
> In a module, you write that all down in the manifest with the order
> that you want packages built in and if you need to loop through them
> with different options. Then MBS does the builds in an automated
> fashion and it is repeatable. To me this is the biggest win here as
> for various groups of mass-rebuilds it cuts down errors when order
> matters and you have to do multiple ones to get from package set A to
> package set A+1.
> 
> Making it easier to make flatpacks and stuff also is built into the
> tools which came with modularity. The tools which were doing it for
> the Fedora buildsystem before this  were 'fragile'.
> 
> Yes a packager or system administrator can build these things without
> the modularity build system but trying to do it in scale in Fedora
> ended up needing the tools which came with MBS.

While the tooling came at the same time, it doesn't necessarily need 
Modularity. See Ken Dreyer's example in the above subthread.

We don't need Modules to do a lot of things that happened to drop around the 
same time, or that were created to work with Modularity.

-- 
John M. Harris, Jr.

___
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

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Kevin Kofler]

Luya Tshimbalanga wrote:
> On 2020-06-16 2:33 p.m., Kevin Kofler wrote:
>> Michael Catanzaro wrote:
>>> No, see the existing f32-backgrounds.spec for how the subpackaging
>>> works. Animated backgrounds are in a separate subpackage that spins do
>>> not need to install.
>> My question was whether this Change intends to change that or whether it
>> will stay as now. The formulation is unclear.
>>
>> If the subpackaging remains as now, that is good.
>>
>>  Kevin Kofler
> The change applied for Fedora 33 while the current subppackages for F32
> remains as it is as answered.

So you intend to change the subpackaging for Fedora 33? Please don't. The 
animated backgrounds should remain in a subpackage so that they are only 
installed on those desktop environments that actually support the animations 
and do not waste space everywhere else.

Backgrounds are a significant source of bloat for our live images (also 
because JPEG images are already compressed and hence are not or only barely 
compressible by xz (or zstd or whatever)). So it is really important to not 
install variants that will not actually be used.

Kevin Kofler
___
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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Gary Buhrmaster wrote:

> On Wed, Jun 17, 2020 at 5:41 AM Igor Raits
>  wrote:
> 
>>
>> %if (0%{?rhel} && 0%{?rhel}) <= 8 || (0%{?fedora} && 0%{?fedora} <= 32)
>>
> 
> Yes, I have written such spec file lines, and while
> they are correct, they tend to be ugly to parse for
> humans.

Apparently also to linearize (unparse), as evidenced by the typo (misplaced 
closing parenthesis) in Igor's line. :-) (Hint: Comparing a boolean 
expression with 8 does not make sense.)

Kevin Kofler
___
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

Re: Modules building for Fedora 30

[Orion Poplawski]

On 6/20/20 11:32 AM, Kevin Fenzi wrote:

On Sat, Jun 20, 2020 at 09:45:15AM -0400, Stephen John Smoogen wrote:

On Fri, 19 Jun 2020 at 23:16, Orion Poplawski  wrote:


I just noticed that my openmpi module build is building for Fedora 30.
This seems like a mistake.  Where do I report that?



I think it should be reported here: https://pagure.io/releng/issues


Yeah, thats fine, or infrastructure.

I'm not sure however where that is configured, so it might be some
digging before we can fix it. None of: '30' 'fedora-30' 'platform:f30'
appear in the mbs configuration. ;(

kevin


Filed https://pagure.io/releng/issue/9542

Happy hunting! :)


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Miro Hrončok]

On 20. 06. 20 23:18, Björn Persson wrote:

Also: Is it set in stone that "make_build" means "make in parallel" and
nothing else? If so, why isn't the macro called "parallel_make"?

Or is it the case that "make_build" means "the typical make command to
use in a build stage", and a future version of the macro may include
other parameters that are considered useful in a build stage but may
not be appropriate for other use cases? In that case the macro should
only be applied in the %build section, and any make invocation that
looks less than typical should be left alone.


Excellent point, Björn!

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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