Re: RHEL 9 and modularity

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 22, 2020 at 03:36:30PM -0400, Josh Boyer wrote:
> On Mon, Jun 22, 2020 at 1:27 PM Miro Hrončok  wrote:
> >
> > On 18. 06. 20 21:22, Josh Boyer wrote:
> > > The introduction
> > > of default module streams was a direct result of wanting to help
> > > customers that are used to running 'yum install mariadb' still be able
> > > to do that.
> >
> > Hello Josh.
> >
> > I'd like to ask whether RHEL 9 has decided for default modular streams 
> > despite
> > their failure in Fedora, whether this decision is final and what was the
> > reasoning behind it.

Hi Josh, Miro,

I think there has been a misunderstanding. I'm pretty sure Miro's
question is about "default modules" not "default streams"
(i.e. "modules enabled by default" vs. "the stream of a module to use
when a different one is not explicitly selected").
Default streams are not subject of much discussion. There is no plan
to limit them either in Fedora or ELN. But from your reply it is not
clear which of those you have in mind. Let's please clarify what we're
talking about first...

Zbyszek

> That's an interesting question.  I think for the purposes of this
> discussion, we should acknowledge that usage of default module streams
> in Fedora and usage in RHEL aren't equivalent.  Therefore, failure of
> adoption in Fedora doesn't necessarily equate to failure in RHEL.
> With that context, I'll continue.
> 
> > When discussing default modular streams in ELN, we have heard that ELN needs
> > default streams because RHEL 9 needs them. I would like to know if this
> > information is something that comes from RHEL leadership directly or 
> > whether it
> > is a personal option of the people who said such things.
> 
> Why does it matter if "RHEL leadership" said it, or if a RHEL package
> maintainer said it?  Politely, I find that an odd way to frame that
> discussion, devalues individual team autonomy, and ignores what the
> conversation points should be.  Let me suggest a different way.
> 
> We know within RHEL we have teams that will likely continue using
> default streams.  We also know that some teams will not.  Further we
> know that somes teams will likely not use modules at all, just as
> teams in RHEL 8 did not use modules.  The flexibility to choose the
> approach that makes the most sense for that team and their package set
> would be what I would hope we try to enable in Fedora and ELN.  It is
> fair to ask why a team would want to continue using default streams,
> and I can offer guesses but they would be only that.  I would hope
> such teams could freely chime in here.  The point is, within RHEL it
> is actually their choice to make, balancing the needs of their
> customers with the content they are packaging, etc.
> 
> It remains unclear to me why Fedora would go out of its way to
> disallow usage of default streams in ELN.  I understand they can
> present some issues if used incorrectly, or for something that is core
> to non-modular content, but the concept of a default stream being
> forbidden outright is strange.  Default streams in ELN don't impact
> the wider Fedora distribution and removing them eliminates options and
> flexibility, forcing their usage to become a downstream-only concept
> which is exactly what we're trying to avoid with ELN to begin with.
> 
> 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
___
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: CPE Weekly: 2020-06-21

[Kevin Fenzi]

On Mon, Jun 22, 2020 at 03:57:28PM +0800, Qiyu Yan wrote:
> Ronaldo Mercado  于2020年6月22日周一 下午3:43写道：
> >
> > Thanks for your message.
> >
> > > See our wiki page here for more
> > > information:https://docs.fedoraproject.org/en-US/cpe/
> >
> > I am replying because the link in your message reports "403 Forbidden"
> I think that is because the data center move somehow brokes
> docs.fedoraproject.org, wait for it to restore.

It actually wasn't the datacenter move, it was some issues we had on the
docs building pipeline. All of them should be solved now and it should
be back up for everyone. If you still see any issues, feel free to open
a ticket: https://pagure.io/fedora-infrastructure/issues

Sorry for the outage. 

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

[Kevin Kofler]

Tom Stellard wrote:
> The benefits for using the macro are mentioned in the proposal, so this is
> not just a cosmetic change.

I have addressed those points further down in my message: I do not believe 
that the proposed change will achieve the mentioned goals, and I think the 
side effects are worse than what it can fix. See my detailed replies in the 
remainder of both my previous message and this message.

> I think making it easier to standardize the build flags in Fedora is an
> important benefit as we currently have a gap in the project where packages
> that use make without a build system generator like autoconf or cmake do
> not have the correct build flags added automatically.

But there is no way RPM macros can address this problem, because there is no 
standardized way to pass build flags to a handwritten makefile:
* The makefile may or may not honor environment variables. And passing -e to
  make to try to force it may or may not work. (It can cause more problems
  than it solves. In particular, -e is always detrimental for packages that
  actually do use a makefile generator.)
* The makefile may or may not use standardized variable names such as
  CFLAGS. I have seen makefiles hardcode the flags entirely or use arbitrary
  names, such as COMPILER_FLAGS, GCC_FLAGS, COMPILER_OPTIONS or whatever.
  (Or worse, they may use standard variable names with subtly different
  semantics, e.g., CPP_FLAGS for C++ compiler flags.)
* Required flags may or may not be defined within CFLAGS. If they are, then
  just overriding CFLAGS with the distro defaults will likely break the
  package's build.

Handwritten makefiles are exactly the case where it is NOT safe to use a 
stock macro such as %make_build. Such standardized macros can only possibly 
work for packages using a popular build system, and for those, the configure 
step is the right place to apply build flags.

> Packages will be tested using the koji-simple-ci job, which does a scratch
> build when a pull request is submitted.  You are correct that this is not
> a 100% guarantee to catch parallel build issues.  However, the downside
> of missing a parallel build issue is very limited as package maintainers
> can easily undo this change.

Sorry, I do not consider it acceptable to mass-break packages by default and 
to require maintainers to explicitly unbreak them.

The only safe way is to assume that packages that do not use %{_smp_mflags} 
omit it for a reason.

> I have not found this to be the case.  I have implemented the proposed
> change in some packages already and I found packages that were not using
> %{_smp_mflags} that did benefit from parallel builds.

Then file bugs against those packages asking them to add %{_smp_mflags}. The 
guidelines explicitly state that it should always be used if it works. 

But don't be surprised if many of those bugs get closed as NOTABUG because 
the %{_smp_mflags} were omitted or removed for a reason that you were not 
aware of.

> I'm thinking about compiler flags, like CFLAGS or even possibly compiler
> variables, like CC and CXX.  And they would not necessarily be passed as
> arguments directly to make.  One option would be to have %make_build
> call the %set_build_flags macro which sets up environment variables with
> the correct flags.

Most handwritten makefiles ignore environment variables entirely. Something 
like:
CFLAGS=-foo
or even:
CFLAGS+=-foo
takes precedence over environment variables. (Unless you pass make -e, which 
will make it ignore even the += lines, and which can also cause other 
problems.)

Only ?= honors environment variables, and many handwritten makefiles do not 
use it, or at least not consistently.

And handwritten makefiles also do not necessarily use the conventional names 
(CFLAGS, CC, CXX, etc.). They can use arbitrary variable names, or no 
variables at all (i.e., everything hardcoded).

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: client.cpp:104:47: error: '_1' was not declared in this scope

[José Abílio Matos]

On Monday, 22 June 2020 20.05.45 WEST Martin Gansser wrote:
> Hi,
> 
> I am trying to compile bear-engine for rawhide, but this fails with the
> following error message [1]:
> /builddir/build/BUILD/bear-c873f289d860a2e11d36a2e619ea8c51167098c4/bear-en
> gine/core/src/net/code/client.cpp: In member function 'void
> bear::net::client::connect()':
> /builddir/build/BUILD/bear-c873f289d860a2e11d36a2e619ea8c51167098c4/bear-en
> gine/core/src/net/code/client.cpp:104:47: error: '_1' was not declared in
> this scope 104 | ( boost::bind( &client::set_stream, this, _1 ),
> 
>   |   ^~
> 
> 
> How can i solve this ?
> 
> [1] https://kojipkgs.fedoraproject.org//work/tasks/4853/45994853/build.log
> 
> Regards
> Martin

See
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/
SSKNR5UC5QW7LMBQWTEMSBD6RB25PHLO/[1] 

and

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/
MQZJY7O6DS3XUWUTAO2V6SXJ4F5YJN4W/[2] 
-- 
José Abílio


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/
SSKNR5UC5QW7LMBQWTEMSBD6RB25PHLO/
[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/
MQZJY7O6DS3XUWUTAO2V6SXJ4F5YJN4W/
___
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

[Josh Boyer]

On Mon, Jun 22, 2020 at 1:27 PM Miro Hrončok  wrote:
>
> On 18. 06. 20 21:22, Josh Boyer wrote:
> > The introduction
> > of default module streams was a direct result of wanting to help
> > customers that are used to running 'yum install mariadb' still be able
> > to do that.
>
> Hello Josh.
>
> I'd like to ask whether RHEL 9 has decided for default modular streams despite
> their failure in Fedora, whether this decision is final and what was the
> reasoning behind it.

That's an interesting question.  I think for the purposes of this
discussion, we should acknowledge that usage of default module streams
in Fedora and usage in RHEL aren't equivalent.  Therefore, failure of
adoption in Fedora doesn't necessarily equate to failure in RHEL.
With that context, I'll continue.

> When discussing default modular streams in ELN, we have heard that ELN needs
> default streams because RHEL 9 needs them. I would like to know if this
> information is something that comes from RHEL leadership directly or whether 
> it
> is a personal option of the people who said such things.

Why does it matter if "RHEL leadership" said it, or if a RHEL package
maintainer said it?  Politely, I find that an odd way to frame that
discussion, devalues individual team autonomy, and ignores what the
conversation points should be.  Let me suggest a different way.

We know within RHEL we have teams that will likely continue using
default streams.  We also know that some teams will not.  Further we
know that somes teams will likely not use modules at all, just as
teams in RHEL 8 did not use modules.  The flexibility to choose the
approach that makes the most sense for that team and their package set
would be what I would hope we try to enable in Fedora and ELN.  It is
fair to ask why a team would want to continue using default streams,
and I can offer guesses but they would be only that.  I would hope
such teams could freely chime in here.  The point is, within RHEL it
is actually their choice to make, balancing the needs of their
customers with the content they are packaging, etc.

It remains unclear to me why Fedora would go out of its way to
disallow usage of default streams in ELN.  I understand they can
present some issues if used incorrectly, or for something that is core
to non-modular content, but the concept of a default stream being
forbidden outright is strange.  Default streams in ELN don't impact
the wider Fedora distribution and removing them eliminates options and
flexibility, forcing their usage to become a downstream-only concept
which is exactly what we're trying to avoid with ELN to begin with.

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

Re: Bodhi 5.4.0 in production

[Richard Shaw]

Just submitted another set of updates and it worked as expected. Not sure
if it was an infra issue or maybe there was something / a character in the
notes it just didn't like.

Thanks,
Richard

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

client.cpp:104:47: error: '_1' was not declared in this scope

[Martin Gansser]

Hi,

I am trying to compile bear-engine for rawhide, but this fails with the 
following error message [1]:
/builddir/build/BUILD/bear-c873f289d860a2e11d36a2e619ea8c51167098c4/bear-engine/core/src/net/code/client.cpp:
 In member function 'void bear::net::client::connect()':
/builddir/build/BUILD/bear-c873f289d860a2e11d36a2e619ea8c51167098c4/bear-engine/core/src/net/code/client.cpp:104:47:
 error: '_1' was not declared in this scope
  104 | ( boost::bind( &client::set_stream, this, _1 ),
  |   ^~

How can i solve this ?

[1] https://kojipkgs.fedoraproject.org//work/tasks/4853/45994853/build.log

Regards
Martin
___
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

[Tom Stellard]

On 06/22/2020 10:54 AM, Björn Persson wrote:
> Tom Stellard wrote:
>> On 06/22/2020 10:00 AM, Björn Persson wrote:
>>> Tom Stellard wrote:  
 The reason I put in the proposal that all make invocations would be 
 updated,
 is because this is easier to script and it would be hard for someone who
 doesn't know the package to make the call about which invocations don't
 need to use parallel make.  
>>>
>>> It's often tempting to do the easy thing instead of the right thing.
>>
>> What do you think would be the right thing to do in this case?
> 
> To study each make invocation, determine whether it's parallelizable
> and judge whether future build flags will be appropriate – which is
> obviously much more work for the person pushing the change, but avoids
> making work for package maintainers.
> 

I think that even if the change owner does the analysis themselves, the
package maintainer is still going to want to review the changes.  So,
I don't know if doing it this way would actually save maintainers work.

-Tom

> Björn Persson
> 
> 
> 
> ___
> 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: protobuf update coming to rawhide

[Adrian Reber]

On Mon, Jun 15, 2020 at 06:51:32AM +0200, Adrian Reber wrote:
> I prepared a protobuf update for rawhide to 3.12. It requires a rebuild
> of all dependencies and of the 55 dependencies currently 10 fail to
> rebuild. The following packages are failing:
> 
> clementine
> closure-compiler
> fawkes
> gazebo
> hidviz
> kismet
> libgadu
> mir
> mozc
> pokerth
> 
> and the failures do not seem to be protobuf related. See
> 
> https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-12/

All rebuilds have finished and from the previously 10 reported
failures 9 are still not building. None of the failures seem
to be protobuf related:

opencv: requires gtkglext which requires pangox-compat (dead.package)
gazebo: requires opencv
fawkes: requires gazebo

pokerth: build failures related to boost

mozc:
   
/builddir/build/BUILD/mozc-2.23.2815.102/dictionary/user_dictionary_storage.h:77:7:
 error: cannot derive from ‘final’ base 
‘mozc::user_dictionary::UserDictionaryStorage’ in derived type 
‘mozc::UserDictionaryStorage’
   77 | class UserDictionaryStorage : public 
user_dictionary::UserDictionaryStorage {
  |   ^

mir:
   ../src/miral/external_client.cpp:46:24: error: 'find' was not declared in 
this scope
   46 | auto const j = find(i, end(value), ':');
  |^~~~

hidviz:
   /usr/bin/ld: CMakeFiles/hidviz.dir/src/DeviceSelector.cc.o: in function 
`hidviz::DeviceSelector::~DeviceSelector()':
   /builddir/build/BUILD/hidviz-0.1.5/hidviz/src/DeviceSelector.cc:46: 
undefined reference to `vtable for hidviz::DeviceSelector'

closure-compiler: No matching package to install: 
'mvn(com.google.guava:guava:20.0)'

kismet:
   + /bin/cp -a /usr/lib/rpm/config.sub .
   /bin/cp: cannot stat '/usr/lib/rpm/config.sub': No such file or directory

The packages have been built in f33-build-side-24661 and I will create
the side-tag update later today to get all builds into rawhide.

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

[Tom Stellard]

On 06/22/2020 10:14 AM, Neal Gompa wrote:
> On Mon, Jun 22, 2020 at 11:51 AM Tom Stellard  wrote:
>>
>> On 06/20/2020 11:20 AM, Neal Gompa wrote:
>>> 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.
>>>
>>
>> Is this because you are concerned about build failures caused by
>> enabling parallel builds for packages that aren't currently using
>> that?
>>
> 
> Yes, and because Make is often used for non-compilation things and
> those aren't necessarily multi-threaded, and passing mflags there can
> break things.
> 
> 

If replacing 'make %{?_smp_mflags}' with %make_build is the only change
that is done, then I don't think this change proposal would be worth
doing.  This would eliminate one of the benefits (increased build parallelism),
and also not help that much with the other stated benefit of enforcing
consistent build flag usage, since many packages would sill be using just 
'make'.

Another possible solution to the issues you raise would be to restrict the
scope of this proposal to only make 'build', check, and install targets.

-Tom





___
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

[Björn Persson]

Tom Stellard wrote:
> On 06/22/2020 10:00 AM, Björn Persson wrote:
> > Tom Stellard wrote:  
> >> The reason I put in the proposal that all make invocations would be 
> >> updated,
> >> is because this is easier to script and it would be hard for someone who
> >> doesn't know the package to make the call about which invocations don't
> >> need to use parallel make.  
> > 
> > It's often tempting to do the easy thing instead of the right thing.
> 
> What do you think would be the right thing to do in this case?

To study each make invocation, determine whether it's parallelizable
and judge whether future build flags will be appropriate – which is
obviously much more work for the person pushing the change, but avoids
making work for package maintainers.

Björn Persson


pgpE4hqIKgNns.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: Orphaned 215 packages

[Jared K. Smith]

On Mon, Jun 22, 2020 at 11:29 AM Ben Rosser  wrote:

> However... what should we do in the meantime to stop further nodejs
> software from being orphaned and retired?
>

>From my standpoint, the answer to this is around tooling to
built/test/audit NodeJS applications with bundled dependencies.  Easier
said than done, unfortunately :-/

I've gone ahead and taken mocha (running tests will be useful
> regardless of whether or not we start bundling NPM modules). I haven't
> yet figured out what I need to take to keep it + my other node
> packages alive for now, but I'll work through that this evening if no
> one suggests doing anything else.
>

Thank you!  I'm happy to help where I can, but can't quite guarantee right
now that I have the time to be the primary maintainer of the mocha
package.  That being said, if you get stuck, feel free to ping me on IRC or
drop me an email, and I'll try to help.

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

[Miro Hrončok]

On 18. 06. 20 21:22, Josh Boyer wrote:

The introduction
of default module streams was a direct result of wanting to help
customers that are used to running 'yum install mariadb' still be able
to do that.


Hello Josh.

I'd like to ask whether RHEL 9 has decided for default modular streams despite 
their failure in Fedora, whether this decision is final and what was the 
reasoning behind it.


When discussing default modular streams in ELN, we have heard that ELN needs 
default streams because RHEL 9 needs them. I would like to know if this 
information is something that comes from RHEL leadership directly or whether it 
is a personal option of the people who said such things.


Thanks,
--
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

[Neal Gompa]

On Mon, Jun 22, 2020 at 11:51 AM Tom Stellard  wrote:
>
> On 06/20/2020 11:20 AM, Neal Gompa wrote:
> > 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.
> >
>
> Is this because you are concerned about build failures caused by
> enabling parallel builds for packages that aren't currently using
> that?
>

Yes, and because Make is often used for non-compilation things and
those aren't necessarily multi-threaded, and passing mflags there can
break things.


-- 
真実はいつも一つ！/ 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

[Tom Stellard]

On 06/22/2020 10:00 AM, Björn Persson wrote:
> Tom Stellard wrote:
>> The reason I put in the proposal that all make invocations would be updated,
>> is because this is easier to script and it would be hard for someone who
>> doesn't know the package to make the call about which invocations don't
>> need to use parallel make.
> 
> It's often tempting to do the easy thing instead of the right thing.
> 

What do you think would be the right thing to do in this case?

-Tom

> Björn Persson
> 
> 
> 
> ___
> 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

[Björn Persson]

Tom Stellard wrote:
> The reason I put in the proposal that all make invocations would be updated,
> is because this is easier to script and it would be hard for someone who
> doesn't know the package to make the call about which invocations don't
> need to use parallel make.

It's often tempting to do the easy thing instead of the right thing.

Björn Persson


pgpWHSF2JHpRj.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

Fedora rawhide compose report: 20200622.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200620.n.1
NEW: Fedora-Rawhide-20200622.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  4
Dropped packages:0
Upgraded packages:   85
Downgraded packages: 0

Size of added packages:  204.40 KiB
Size of dropped packages:0 B
Size of upgraded packages:   2.75 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   19.96 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20200622.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20200622.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: andriller-3.3.1-1.fc33
Summary: Android Forensic Tools
RPMs:andriller
Size:127.62 KiB

Package: golang-github-andreasbriese-bbloom-0-0.1.20200621git46b345b.fc33
Summary: Fast bit set Bloom filter
RPMs:golang-github-andreasbriese-bbloom-devel
Size:16.53 KiB

Package: rust-obfstr-0.1.1-1.fc33
Summary: Compiletime string literal obfuscation for Rust
RPMs:rust-obfstr+default-devel rust-obfstr+rand-devel 
rust-obfstr+unsafe_static_str-devel rust-obfstr-devel
Size:34.73 KiB

Package: rust-obfstr-impl-0.1.1-1.fc33
Summary: Procedural macro implementation for obfstr
RPMs:rust-obfstr-impl+default-devel rust-obfstr-impl+rand-devel 
rust-obfstr-impl-devel
Size:25.52 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  BackupPC-4.4.0-1.fc33
Old package:  BackupPC-4.3.2-3.fc33
Summary:  High-performance backup system
RPMs: BackupPC
Size: 2.11 MiB
Size change:  40.54 KiB
Changelog:
  * Sun Jun 21 2020 Richard Shaw  - 4.4.0-1
  - Update to 4.4.0.


Package:  BackupPC-XS-0.62-1.fc33
Old package:  BackupPC-XS-0.60-1.fc33
Summary:  Implementation of various BackupPC functions in a perl-callable 
module
RPMs: BackupPC-XS
Size: 563.57 KiB
Size change:  4.55 KiB
Changelog:
  * Sun Jun 21 2020 Richard Shaw  - 0.62-1
  - Update to 0.62.


Package:  Lmod-8.3.16-1.fc33
Old package:  Lmod-8.3.15-1.fc33
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.05 MiB
Size change:  750 B
Changelog:
  * Sat Jun 20 2020 Orion Poplawski  - 8.3.16-1
  - Update to 8.3.16


Package:  R-stringi-1.4.6-4.fc33
Old package:  R-stringi-1.4.6-2.fc33
Summary:  Character String Processing Facilities
RPMs: R-stringi R-stringi-devel
Size: 4.77 MiB
Size change:  5.39 KiB
Changelog:
  * Mon Jun 15 2020 Pete Walter  - 1.4.6-3
  - Rebuild for ICU 67

  * Sat Jun 20 2020 Dennis Gilmore  - 1.4.6-4
  - rebuild for R 4.0.1


Package:  adns-1.6.0-1.fc33
Old package:  adns-1.5.1-10.fc33
Summary:  Advanced, easy to use, asynchronous-capable DNS client library
RPMs: adns adns-devel adns-progs
Size: 767.40 KiB
Size change:  15.93 KiB
Changelog:
  * Sun Jun 21 2020 S??rgio Basto  - 1.6.0-1
  - Update adns to 1.6.0 (#1846479)
  - Drop patch0, upstream fixed patch0 in another way


Package:  apache-sshd-1:2.4.0-1.fc33
Old package:  apache-sshd-1:2.2.0-4.fc32
Summary:  Apache SSHD
RPMs: apache-sshd apache-sshd-javadoc
Size: 3.20 MiB
Size change:  169.42 KiB
Changelog:
  * Mon Jun 22 2020 Mat Booth  - 1:2.4.0-1
  - Update to latest upstream release


Package:  chromium-83.0.4103.106-1.fc33
Old package:  chromium-83.0.4103.97-3.fc33
Summary:  A WebKit (Blink) powered web browser
RPMs: chromedriver chromium chromium-common chromium-headless
Size: 321.05 MiB
Size change:  -980.88 KiB
Changelog:
  * Mon Jun 15 2020 Tom Callaway  - 83.0.4103.97-4
  - use old cups handling on epel7
  - fix skia attribute overrides with gcc

  * Tue Jun 16 2020 Tom Callaway  - 83.0.4103.97-5
  - add ServiceWorker fix

  * Thu Jun 18 2020 Tom Callaway  - 83.0.4103.106-1
  - update to 83.0.4103.106
  - remove duplicate ServiceWorker fix
  - add fix to work around gcc bug on aarch64
  - disable python byte compiling (we do not need it)


Package:  cinnamon-4.6.5-1.fc33
Old package:  cinnamon-4.6.4-1.fc33
Summary:  Window management and application launching for GNOME
RPMs: cinnamon cinnamon-devel-doc
Size: 8.26 MiB
Size change:  67 B
Changelog:
  * Sun Jun 21 2020 Leigh Scott  - 4.6.5-1
  - Update to 4.6.5 release


Package:  cinnamon-control-center-4.6.1-1.fc33
Old package:  cinnamon-control-center-4.6.0-1.fc33
Summary:  Utilities to configure the Cinnamon desktop
RPMs: cinnamon-control-center cinnamon-control-center-devel 
cinnamon-control-center-filesystem
Size: 11.22 MiB
Size change:  2.87 KiB
Changelog:
  * Sun Jun 21 2020 Leigh Scott  - 4.6.1-1
  - Update to 4.6.1 release


Package:  cinnamon-desktop-4.6.2-1.fc33
Old package:  cinnamon-desktop-4.6.1-1.fc33
Summary:  Shared code among cinnamon-session, nemo, etc
RPMs: cinnamon-desktop

Re: Bodhi 5.4.0 in production

[Richard Shaw]

On Mon, Jun 22, 2020 at 11:16 AM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Il 22/06/20 17:42, Richard Shaw ha scritto:
> > I couple of observations after recently submitting some buildroot
> > overrides and updates:
> >
> > Updates:
> > 1. Preview for the update notes is completely broken.
> Everything works fine for me and the update form hasn't been touched in
> the update from 5.2.2.
> Can you check in the browser console if any error is displayed when
> opening the preview popup?
>

It either said something to the effect of "Preview Failed" or just stalled.

Thanks,
Richard
___
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

[Tom Stellard]

On 06/20/2020 05:11 PM, Kevin Kofler wrote:
> 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 benefits for using the macro are mentioned in the proposal, so this is not
just a cosmetic change.  I think making it easier to standardize the build
flags in Fedora is an important benefit as we currently have a gap in the
project where packages that use make without a build system generator 
like autoconf or cmake do not have the correct build flags added automatically.

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

I agree with this, and I will update the proposal to use %make_build -j1 
instead.

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

Packages will be tested using the koji-simple-ci job, which does a scratch
build when a pull request is submitted.  You are correct that this is not
a 100% guarantee to catch parallel build issues.  However, the downside
of missing a parallel build issue is very limited as package maintainers
can easily undo this change.

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

I have not found this to be the case.  I have implemented the proposed change
in some packages already and I found packages that were not using %{_smp_mflags}
that did benefit from parallel builds.


> 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.)

I'm thinking about compiler flags, like CFLAGS or even possibly compiler
variables, like CC and CXX.  And they would not necessarily be passed as
arguments directly to make.  One option would be to have %make_build
call the %set_build_flags macro which sets up environment variables with
the correct flags.

-Tom

> 
> 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
> 
___
devel ma

Re: Bodhi 5.4.0 in production

[Mattia Verga via devel]

Il 22/06/20 17:42, Richard Shaw ha scritto:
> I couple of observations after recently submitting some buildroot 
> overrides and updates:
>
> Buildroot overrides:
> 1. The new auto-search with partial build names is nice but clicking 
> on the builds it findes has no effect.
> 2. When I manually paste in a full build name it says "No results" but 
> works when submitted.
Yeah, this is not working as expected. Also, the search query should use 
a prefix, not the full package name, so that definitively needs a fix.
>
> Updates:
> 1. Preview for the update notes is completely broken.
Everything works fine for me and the update form hasn't been touched in 
the update from 5.2.2.
Can you check in the browser console if any error is displayed when 
opening the preview popup?

Mattia

___
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 packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Dominik 'Rathann' Mierzejewski]

On Monday, 22 June 2020 at 17:17, Vitaly Zaitsev via devel wrote:
> On 22.06.2020 17:09, Dominik 'Rathann' Mierzejewski wrote:
> > Cc'ing fmt maintainers.
> 
> fmt co-maintainer here. Sorry, but I don't like nodejs, so I don't want
> to take them.

I wasn't asking for that. I only suggested dropping the dependency,
which means you can't rebuild the docs anymore. Thanks for maintaining
fmt so far.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

[Ben Rosser]

On Mon, Jun 22, 2020 at 11:34 AM Sérgio Basto  wrote:
>
> On Mon, 2020-06-22 at 11:29 -0400, Ben Rosser wrote:
> > On Thu, Jun 18, 2020 at 3:09 PM Stephen Gallagher <
> > sgall...@redhat.com> wrote:
> > > The Node.js SIG is very loosely organized. If you are a packager
> > > and
> > > write to the SIG to ask to be added to the FAS group
> > > gitnodejs-packaging, I'll go ahead and add you.
> >
> > Hi Stephen,
> >
> > Thanks. I'll send an email to the SIG mailing list.
>
> What is the SIG mailing list ?  I'm confused

Well, the one I'm subscribed to is the same one that's CC'ed on this
thread (and linked to on the wiki)-- nod...@lists.fedoraproject.org.
Not sure if there is also another list.
https://lists.fedoraproject.org/admin/lists/nodejs.lists.fedoraproject.org/

Ben Rosser
___
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

[Tom Stellard]

On 06/20/2020 11:20 AM, Neal Gompa wrote:
> 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.
> 

Is this because you are concerned about build failures caused by
enabling parallel builds for packages that aren't currently using
that?

-Tom

> As for "make DESTDIR=%{buildroot} install" to "%make_install", I'm fine with 
> it.
> 
___
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

[Tom Stellard]

On 06/20/2020 11:14 AM, 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 agree, this would be better.  I am going to update the proposal to
include this.

-Tom

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

[Tom Stellard]

On 06/20/2020 02:23 AM, Dan Čermák wrote:
> 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).
> 

I would be in favor of this.  We run into this issue a lot when building
the LLVM packages.

-Tom

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

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

[Tom Stellard]

On 06/20/2020 02:18 PM, Björn Persson wrote:
> 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.

This is correct, my assumption is that in the future the macro may include
other parameters.  This is what I was referring to in the "Benefit to Fedora"
section when I said: 

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

One possible use case in the future would be to add CFLAGS and CXXFLAGS as 
arguments,
this would ensure that projects using make without a build system generator
like autoconf or cmake would use the correct build flags.

Another use case could be to set the CC and CXX variables to make explicit the 
use
of the Fedora system compiler and also ensure that packages using a different 
compiler
are doing so in the correct way.

This change is about more than just enabling parallel builds, so I do think
we should keep the macro name the same.

As for using this macro in the %check section.  There are 2 advantages to doing 
this:

1. Some packages build code when running `make check`, so parallelizing this 
will still
be a benefit.

2. This will ensure that code built using `make check` uses the same 
compiler/compiler flags
that was used for the default make target.

-Tom
 

> 
> Björn Persson
> 
> 
> 
> ___
> 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: Bodhi 5.4.0 in production

[Richard Shaw]

I couple of observations after recently submitting some buildroot overrides
and updates:

Buildroot overrides:
1. The new auto-search with partial build names is nice but clicking on the
builds it findes has no effect.
2. When I manually paste in a full build name it says "No results" but
works when submitted.

Updates:
1. Preview for the update notes is completely broken.

Thanks,
Richard
___
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 Mon, 2020-06-22 at 11:29 -0400, Ben Rosser wrote:
> On Thu, Jun 18, 2020 at 3:09 PM Stephen Gallagher <
> sgall...@redhat.com> wrote:
> > The Node.js SIG is very loosely organized. If you are a packager
> > and
> > write to the SIG to ask to be added to the FAS group
> > gitnodejs-packaging, I'll go ahead and add you.
> 
> Hi Stephen,
> 
> Thanks. I'll send an email to the SIG mailing list.

What is the SIG mailing list ?  I'm confused 


> 
> > Zuzanna Svetlikova and I maintain the Node.js interpreter and NPM
> > package tool in modular and non-modular Fedora releases. This is
> > not
> > going away. The packaging for these critical packages includes
> > bundled
> > NPM content from upstream rather than consuming packages in Fedora
> > because the Node.js packaging ecosystem makes it realistically
> > impossible to package every individual dependency into RPMs (NPM
> > alone
> > has 402 dependencies and it changes constantly).
> 
> Sure, to be clear I wasn't worried about the interpreter and npm
> itself-- thanks for the work you do maintaining that! I'm primarily
> worried about the npm module ecosystem.
> 
> > I've been meaning to bring up this topic on the Node.js SIG mailing
> > list for a while: I think Fedora should largely get out of the game
> > of
> > delivering NPM modules and only concern itself with delivering
> > tools
> > that provide applications or support for other software in Fedora.
> > So
> > things like ycssmin and lessc would make sense to keep alive, but
> > probably we would build them with their NPM dependencies bundled to
> > match their upstream releases rather than waste time building
> > dozens
> > or hundreds of dependent packages in Fedora.
> > 
> > I have some thoughts on how this could be made easier, but I'll
> > open a
> > different thread on that on nod...@lists.fedoraproject.org to
> > discuss
> > those.
> 
> This seems sad, but probably inevitable given the mess that is the
> npm
> module ecosystem. My experience trying to package nodejs software has
> been that the upstream version requirements on modules are usually
> overly strict and can sometimes (but not always, of course) be
> considerably softened or worked around-- but in order to package
> every
> dependency we'd wind up needing to maintain hundreds if not thousands
> of packages, and it is a lot of work to keep them updated. So I
> suppose I'd be cautiously in favor, provided there was some kind of
> automation to help write/maintain this part of the spec.
> 
> However... what should we do in the meantime to stop further nodejs
> software from being orphaned and retired? I imagine it will take some
> time to put together some tooling and/or guidelines for this, and
> these packages are set to be retired imminently. Can we temporarily
> allow the nodejs SIG fas group to become the POC of these packages to
> stop their retirement?
> 
> I've gone ahead and taken mocha (running tests will be useful
> regardless of whether or not we start bundling NPM modules). I
> haven't
> yet figured out what I need to take to keep it + my other node
> packages alive for now, but I'll work through that this evening if no
> one suggests doing anything else.
> 
> Ben Rosser
> ___
> 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
-- 
Sérgio M. B.
___
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

[Ben Rosser]

On Thu, Jun 18, 2020 at 3:09 PM Stephen Gallagher  wrote:
> The Node.js SIG is very loosely organized. If you are a packager and
> write to the SIG to ask to be added to the FAS group
> gitnodejs-packaging, I'll go ahead and add you.

Hi Stephen,

Thanks. I'll send an email to the SIG mailing list.

> Zuzanna Svetlikova and I maintain the Node.js interpreter and NPM
> package tool in modular and non-modular Fedora releases. This is not
> going away. The packaging for these critical packages includes bundled
> NPM content from upstream rather than consuming packages in Fedora
> because the Node.js packaging ecosystem makes it realistically
> impossible to package every individual dependency into RPMs (NPM alone
> has 402 dependencies and it changes constantly).

Sure, to be clear I wasn't worried about the interpreter and npm
itself-- thanks for the work you do maintaining that! I'm primarily
worried about the npm module ecosystem.

> I've been meaning to bring up this topic on the Node.js SIG mailing
> list for a while: I think Fedora should largely get out of the game of
> delivering NPM modules and only concern itself with delivering tools
> that provide applications or support for other software in Fedora. So
> things like ycssmin and lessc would make sense to keep alive, but
> probably we would build them with their NPM dependencies bundled to
> match their upstream releases rather than waste time building dozens
> or hundreds of dependent packages in Fedora.
>
> I have some thoughts on how this could be made easier, but I'll open a
> different thread on that on nod...@lists.fedoraproject.org to discuss
> those.

This seems sad, but probably inevitable given the mess that is the npm
module ecosystem. My experience trying to package nodejs software has
been that the upstream version requirements on modules are usually
overly strict and can sometimes (but not always, of course) be
considerably softened or worked around-- but in order to package every
dependency we'd wind up needing to maintain hundreds if not thousands
of packages, and it is a lot of work to keep them updated. So I
suppose I'd be cautiously in favor, provided there was some kind of
automation to help write/maintain this part of the spec.

However... what should we do in the meantime to stop further nodejs
software from being orphaned and retired? I imagine it will take some
time to put together some tooling and/or guidelines for this, and
these packages are set to be retired imminently. Can we temporarily
allow the nodejs SIG fas group to become the POC of these packages to
stop their retirement?

I've gone ahead and taken mocha (running tests will be useful
regardless of whether or not we start bundling NPM modules). I haven't
yet figured out what I need to take to keep it + my other node
packages alive for now, but I'll work through that this evening if no
one suggests doing anything else.

Ben Rosser
___
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 22. 06. 20 17:21, Tom Stellard wrote:

On 06/19/2020 03:37 PM, 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 reason I put in the proposal that all make invocations would be updated,
is because this is easier to script and it would be hard for someone who
doesn't know the package to make the call about which invocations don't
need to use parallel make.

However, this issue is also part of the reason I included a 1 week review 
period,
for each change.  I think it would be reasonable for a maintainer to
reject a change for something like `make html` if they felt it was making
the spec file worse with no benefit.


And that works, however I am trying to save you some work as well :)


What if I updated the proposed documentation change to say that
%make_build must be used for 'code building targets', check, and install,
but is optional otherwise?


That would certainly %make_build more sense to me, thanks.

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

[Tom Stellard]

On 06/19/2020 03:37 PM, 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 reason I put in the proposal that all make invocations would be updated,
is because this is easier to script and it would be hard for someone who
doesn't know the package to make the call about which invocations don't
need to use parallel make.

However, this issue is also part of the reason I included a 1 week review 
period,
for each change.  I think it would be reasonable for a maintainer to
reject a change for something like `make html` if they felt it was making
the spec file worse with no benefit.

What if I updated the proposed documentation change to say that
%make_build must be used for 'code building targets', check, and install,
but is optional otherwise?

-Tom
___
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 packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Vitaly Zaitsev via devel]

On 22.06.2020 17:09, Dominik 'Rathann' Mierzejewski wrote:
> Cc'ing fmt maintainers.

fmt co-maintainer here. Sorry, but I don't like nodejs, so I don't want
to take them.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Dominik 'Rathann' Mierzejewski]

On Monday, 22 June 2020 at 14:36, Miro Hrončok wrote:
[...]
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-06-22.txt
> grep it for your FAS username and follow the dependency chain.
> 
> Package  (co)maintainers   Status 
> Change
> 
[...]
> nodejs-mime   nodejs-sig, orphan, patches  5 weeks ago

Looks like fmt requires nodejs-less to build documentation[1], which
depends on nodejs-mime. fmt is a dependency of some important packages,
including ceph, so I suggest dropping doc rebuilding from fmt to cut the
dependency tree.

Cc'ing fmt maintainers.

[1] https://src.fedoraproject.org/rpms/fmt/blob/master/f/fmt.spec#_28

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

[Tom Stellard]

On 06/19/2020 03:17 PM, Tomasz Kłoczko wrote:
> On Fri, 19 Jun 2020 at 22:20, 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
> 
> 
> Sometimes only %build or %install or %check is failing.

That's a good point.  What if as an alternative as part of
this change, we used %make_build -j1 in the case where
parallel building does not work?

> Any -j1 tweaks should be *only temporary* so IMO formalising this kind of 
> changes is pointless.
> All parallel build issues should be treated *as critical bugs* which should 
> be *ASAP fixed*.


So are you saying that we should not document the %make_build -j1 convention
and instead update the documentation to state that parallel build failures must 
be
fixed?

Even if we don't document this new convention, I still thing it should
be used for this change, because I think having %make_build -j1 makes it
obvious something is broken and more likely to get fixed.

-Tom

> 
> kloczek
> -- 
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> 
> 
> ___
> 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

Orphaned seven (mostly) unused Java packages

[Fabio Valentini]

I have just orphaned seven (mostly) unused packages that were
previously maintained by the Stewardship SIG.

- felix-bundlerepository: now an unused leaf package in rawhide
- felix-osgi-obr: only required by felix-bundlerepository
- felix-shell: only required by felix-bundlerepository
- joda-convert: no longer needed by the Stewardship SIG
- maven-osgi: no longer needed by the Stewardship SIG
- kxml: only required by felix-bundlerepository
- woodstox-core: only required by felix-bundlerepository
- stax2-api: only required by woodstox-core

Fabio
___
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 packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Christopher Engelhard]

It was orphaned, due to lack of time [1].
I'd be happy to take it.

Best,
Christopher


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XCLRSHRQBJRW5FPGIMBGOIH2KYLVSBNH/#XCLRSHRQBJRW5FPGIMBGOIH2KYLVSBNH
___
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 packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[François Cami]

On Mon, Jun 22, 2020 at 3:15 PM Miro Hrončok  wrote:
>
> On 22. 06. 20 15:02, François Cami wrote:
> > Hi,
> >
> > On Mon, Jun 22, 2020 at 2:38 PM Miro Hrončok  wrote:
> >>
> >> The following packages are orphaned and will be retired when they
> >> are orphaned for six weeks, unless someone adopts them. If you know for 
> >> sure
> >> that the package should be retired, please do so now with a proper reason:
> >> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> >>
> >> Note: If you received this mail directly you (co)maintain one of the 
> >> affected
> >> packages or a package that depends on one. Please adopt the affected 
> >> package or
> >> retire your depending package to avoid broken dependencies, otherwise your
> >> package will be retired when the affected package gets retired.
> >>
> >> Request package ownership via the *Take* button in he left column on
> >> https://src.fedoraproject.org/rpms/
> >>
> >> Full report available at:
> >> https://churchyard.fedorapeople.org/orphans-2020-06-22.txt
> >> grep it for your FAS username and follow the dependency chain.
> >>
> >>   Package  (co)maintainers   
> >> Status Change
> >> 
> >> nodejs-wordwrap   nodejs-sig, orphan, patches  5 weeks 
> >> ago
> >
> > nodejs-yargs (maintained by: fcami, nodejs-sig, pvoborni)
> > nodejs-yargs-3.2.1-12.fc32.noarch requires npm(wordwrap) = 1.0.0
> >
> > The FreeIPA project switched [0] from uglify-js to python-rjsmin. As a
> > result, neither FreeIPA, Petr (pvoborni) nor myself are nodejs-yargs
> > users anymore. Additionally, updating this package to the latest
> > version would require bringing more dependencies into Fedora [1].
> >
> > We do not plan to retire it ourselves just in case anyone needs it and
> > would take nodejs-wordwrap too.
> > In short: nodejs-yargs package will be retired unless someone adopts it.
>
> I suggest you explicitly orphan it in that case. Otherwise it won't be 
> retired,
> but it will be broken and you will get bugzillas opened.

Good advice.

We've just orphaned nodejs-yargs.

François




> --
> 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: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Qiyu Yan]

I am going to take gpredict, I like this software : )
___
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 packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Daniel P . Berrangé]

On Mon, Jun 22, 2020 at 02:36:20PM +0200, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-06-22.txt
> grep it for your FAS username and follow the dependency chain.



> sysfsutilsorphan   2 weeks ago

This one looks like a serious problem which will lead to a very long chain
of broken packages if it is actually removed:


Depending on: sysfsutils (15), status change: 2020-06-02 (2 weeks ago)
bridge-utils (maintained by: dwmw2, twoerner)
bridge-utils-1.6-5.fc32.src requires libsysfs-devel = 
2.1.0-28.fc32

edac-utils (maintained by: mchehab)
edac-utils-0.16-22.fc32.i686 requires libsysfs.so.2, sysfsutils 
= 2.1.0-28.fc32
edac-utils-0.16-22.fc32.src requires libsysfs-devel = 
2.1.0-28.fc32
edac-utils-0.16-22.fc32.x86_64 requires libsysfs.so.2()(64bit), 
sysfsutils = 2.1.0-28.fc32

libmetal (maintained by: jsmith)
libmetal-2020.04.0-1.fc33.i686 requires libsysfs.so.2
libmetal-2020.04.0-1.fc33.src requires libsysfs-devel = 
2.1.0-28.fc32
libmetal-2020.04.0-1.fc33.x86_64 requires libsysfs.so.2()(64bit)

libzfcphbaapi (maintained by: sharkcz)
libzfcphbaapi-2.2.0-6.fc33.src requires libsysfs-devel = 
2.1.0-28.fc32

open-amp (maintained by: pbrobinson)
open-amp-2020.04.0-2.fc33.src requires libsysfs-devel = 
2.1.0-28.fc32
open-amp-2020.04.0-2.fc33.i686 requires libmetal.so.0
open-amp-2020.04.0-2.fc33.x86_64 requires libmetal.so.0()(64bit)

openhpi (maintained by: karsten, pknirsch, rdossant, sharkcz)
openhpi-3.8.0-11.fc33.src requires libsysfs-devel = 
2.1.0-28.fc32
openhpi-3.8.0-11.fc33.x86_64 requires libsysfs.so.2()(64bit)

pcmciautils (maintained by: harald)
pcmciautils-018-18.fc32.src requires libsysfs-devel = 
2.1.0-28.fc32
pcmciautils-018-18.fc32.x86_64 requires libsysfs.so.2()(64bit)

pcsc-cyberjack (maintained by: jenslody, pcfe)
pcsc-cyberjack-3.99.5final.SP13-3.fc32.src requires 
libsysfs-devel = 2.1.0-28.fc32

rng-tools (maintained by: jcapik, nhorman)
rng-tools-6.10-3.fc33.src requires libsysfs-devel = 
2.1.0-28.fc32
rng-tools-6.10-3.fc33.x86_64 requires libsysfs.so.2()(64bit)

sblim-gather (maintained by: vcrhonek)
sblim-gather-2.2.9-16.fc33.src requires libsysfs-devel = 
2.1.0-28.fc32

sblim-smis-hba (maintained by: vcrhonek)
sblim-smis-hba-1.0.0-24.fc33.src requires libsysfs-devel = 
2.1.0-28.fc32

lnst (maintained by: jirka, jtluka, olichtne, rpazdera)
lnst-slave-15-6.fc33.noarch requires bridge-utils = 1.6-5.fc32

netcf (maintained by: berrange, laine)
netcf-libs-0.2.8-15.fc32.i686 requires bridge-utils = 1.6-5.fc32
netcf-libs-0.2.8-15.fc32.x86_64 requires bridge-utils = 
1.6-5.fc32

origin (maintained by: jcajka, tdawson)
origin-sdn-ovs-3.11.1-6.fc33.x86_64 requires bridge-utils = 
1.6-5.fc32

cryptobone (maintained by: senderek)
cryptobone-1.3-1.fc33.x86_64 requires rng-tools = 6.10-3.fc33


netcf-libs will in turn break libvirt, and in turn break much much more.

Anyone know why sysfsutils was orphaned ?  I don't see any FTBFS bugs that
triggered it. Did the maintainer no longer have time, or did they consider
the package obsolete expecting people to use something else instead ?

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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://l

Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Gwyn Ciesla via devel]

I took ORBit2 and loudmouth.

signature.asc
Description: OpenPGP digital 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: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Miro Hrončok]

On 22. 06. 20 15:02, François Cami wrote:

Hi,

On Mon, Jun 22, 2020 at 2:38 PM Miro Hrončok  wrote:


The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-06-22.txt
grep it for your FAS username and follow the dependency chain.

  Package  (co)maintainers   Status 
Change

nodejs-wordwrap   nodejs-sig, orphan, patches  5 weeks ago


nodejs-yargs (maintained by: fcami, nodejs-sig, pvoborni)
nodejs-yargs-3.2.1-12.fc32.noarch requires npm(wordwrap) = 1.0.0

The FreeIPA project switched [0] from uglify-js to python-rjsmin. As a
result, neither FreeIPA, Petr (pvoborni) nor myself are nodejs-yargs
users anymore. Additionally, updating this package to the latest
version would require bringing more dependencies into Fedora [1].

We do not plan to retire it ourselves just in case anyone needs it and
would take nodejs-wordwrap too.
In short: nodejs-yargs package will be retired unless someone adopts it.


I suggest you explicitly orphan it in that case. Otherwise it won't be retired, 
but it will be broken and you will get bugzillas opened.


--
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: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[François Cami]

Hi,

On Mon, Jun 22, 2020 at 2:38 PM Miro Hrončok  wrote:
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-06-22.txt
> grep it for your FAS username and follow the dependency chain.
>
>  Package  (co)maintainers   Status 
> Change
> 
> nodejs-wordwrap   nodejs-sig, orphan, patches  5 weeks ago

nodejs-yargs (maintained by: fcami, nodejs-sig, pvoborni)
nodejs-yargs-3.2.1-12.fc32.noarch requires npm(wordwrap) = 1.0.0

The FreeIPA project switched [0] from uglify-js to python-rjsmin. As a
result, neither FreeIPA, Petr (pvoborni) nor myself are nodejs-yargs
users anymore. Additionally, updating this package to the latest
version would require bringing more dependencies into Fedora [1].

We do not plan to retire it ourselves just in case anyone needs it and
would take nodejs-wordwrap too.
In short: nodejs-yargs package will be retired unless someone adopts it.

François

[0] 
https://src.fedoraproject.org/rpms/freeipa/c/b7be92ba08dca0b16832c9c3e49688a7975f5180?branch=master
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1195743#c220
___
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

Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-06-22.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

CutyCapt  orphan   5 weeks ago
ORBit2alexl, caillon, caolanm, danw,   0 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, rstrode, ssp
abgraph   orphan   3 weeks ago
accrete   orphan   3 weeks ago
amqp  irina, orphan2 weeks ago
apache-commons-vfsmizdebsk, orphan 5 weeks ago
astronomy-backgrounds orphan   3 weeks ago
astronomy-bookmarks   orphan   3 weeks ago
atoum orphan, trasher  0 weeks ago
coro-mock orphan   2 weeks ago
csvdiff   orphan   2 weeks ago
cvsgraph  bojan, orphan3 weeks ago
cvsplot   orphan   3 weeks ago
cvsweborphan   3 weeks ago
datanucleus-maven-parent  orphan   1 weeks ago
dateformatorphan   5 weeks ago
drawtkorphan   4 weeks ago
ebay-cors-filter  orphan   1 weeks ago
eris  bruno, orphan3 weeks ago
felix-framework   mizdebsk, msimacek, orphan   6 weeks ago
felix-osgi-obr-resolver   orphan   6 weeks ago
gcx   orphan   3 weeks ago
ggobi orphan   3 weeks ago
glassfish-hk2 orphan   4 weeks ago
gnome-themes  alexl, caillon, caolanm, 5 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, rstrode, ssp
gobby05   kevin, orphan1 weeks ago
gpredict  orphan   3 weeks ago
gtkglextmmchurchyard, orphan   2 weeks ago
icon-slicer   alexl, caillon, caolanm, 0 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, rstrode, ssp
invokebinder  mmorsi, orphan   2 weeks ago
ircd-ratbox   orphan   3 weeks ago
jasmine   nodejs-sig, orphan, patches  5 weeks ago
jasmine-node  nodejs-sig, orphan, patches  5 weeks ago
javolutionorphan   1 weeks ago
jp2a  mayorga, orphan  2 weeks ago
js-jquery-datetimepicker  orphan   1 weeks ago
js-json   nodejs-sig, orphan   5 weeks ago
js-zlib   nodejs-sig, orphan, patches, 5 weeks ago
  zbyszek
kchildlockorphan   4 weeks ago
kitsune   orphan   5 weeks ago
libgnomecanvasalexl, caillon, caolanm, 0 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, rstrode, ssp
loudmouth fale, lkundrak, maha, orphan,0 weeks ago
  otaylor
mencalorphan   3 weeks ago
mercator 

Re: RHEL 9 and modularity

[Petr Pisar]

On Mon, Jun 22, 2020 at 11:08:14AM +0200, Igor Raits wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Mon, 2020-06-22 at 09:19 +0200, Petr Pisar wrote:
> > On Fri, Jun 19, 2020 at 02:53:56PM -0400, David Cantrell wrote:
> > > 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?
> > > 
> > It can define a build order among packages of a module.
> 
> For that you don't actually have to design some special format. The
> buildsystem should figure this out on its own. And there are such
> buildsystems that do that - Open Build Service.
> 
> > It can change RPM macros in a build root (including SRPM build root).
> 
> I think this is not really good idea, but again - you don't have to
> invent new format for this. Open Build Service allows you to do that in
> a project configuration.
> 
> > It can use transient build dependencies (a package is built, only
> > used as a build
> > dependency of a consquitive package, and then dropped and never
> > shipped).
> 
> Same here.
> 
> > It can build and deliver a package against multiple exclusive
> > dependencies
> > (e.g. for different Fedora releases).
> 
> The same thing.
> 
> > It can build a package from dist-git sources that do not depend on a
> > Fedora
> > release.
> 
> Again, same.
> 
Igor, the question was about modularity. Not about Open Build Service.

-- Petr


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

[Panu Matilainen]

On 6/20/20 9:14 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


Please use this instead:

%global _smp_ncpus_max 1

That allows the same thing to be abstracted to whatever make system 
might be running underneath, some of which have different semantics wrt 
-j arguments or use a different switch altogether etc.




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


This kind of thing gets easily lost in the noise, whereas a macro 
definition is easy to spot and grep for.


- Panu -


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


___
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

[clime]

On Mon, 22 Jun 2020 at 08:14, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Jun 22, 2020 at 04:55:10AM +0200, clime wrote:
> > >> > > Hello Josh,
> > >> > >
> > >> > > you can change the artifact type while keeping interface the same and
> > >> > > it would be a _HUGE_ win because it would make modularity finally
> > >> > > understandable for mere humans and better maintainable.
> > >> > >
> > >> > > Namely, modules should become rpms and therefore obey standard rpm 
> > >> > > rules.
> > >> >
> > >> > I'm not sure I entirely understand what you mean, but it sounds like
> > >> > you have some interesting ideas.
> > >> >
> > >> > I'm looking forward to seeing what you and the community can build
> > >> > from them, and how they could be brought into RHEL 10+!  That kind of
> > >> > collaboration is what makes Fedora great.
> > >>
> > >> I know this probably won't change anything because this was mentioned
> > >> many times (by me at least) and nothing has changed but still...
> > >>
> > >> Currently, modules are essentially yum sub-repos, they are not really
> > >> "modules", instead they are collections of rpms that reinvent rpm-like
> > >> relations (obsoletes, requires, build-requires, etc.).
> > >>
> > >> There is no reason for this wheel-reintervention. Modules (the
> > >> collections) can be simply squashed into an rpm by automation and this
> > >> resulting rpm can go to the modular repo together with other modules.
>
> I agree with this general idea, even if not with the exact implementation
> (comments below). In the past this was stated as "divorcing the build ordering
> mechanism from the rpm delivery mechanism". The fact that we have two layers
> of dependencies make Modularity conceptually hard and destroy the interaction
> with the dependency solver. Also, if we disconnect the build and delivery
> mechanisms, we can iterate and improve both separately.

Indeed, I agree build and delivery mechanisms should be treated independently.

Things would finally get a clear shape.

>
> > >> That way we don't have two types of objects we complex inter-relations
> > >> but only one we well-known behavior.
> > >>
> > >> I wonder if this is clear to everyone but nobody really cares or
> > >> doesn't really want to say it or I don't know.
> > >>
> > >> Is this clear to everyone? I mean either I am stating an obvious stuff
> > >> that nobody really considers worth typing or idk.
> > >
> > >
> > > How would this work when there are optional rpms in the module?
> > >
> > > You do not need to install every rpm in  eg the php module (different 
> > > graphics/database backends) for that module to be useful, but every 
> > > version of the module will have the rpm as an option which wont work 
> > > outside a module of multiple rpms.
> >
> > Glad you ask, I wasn't precise...
> >
> > Well, I didn't mean everything always needs to be squashed, instead,
> > it would be an optional step in modulemd processing.
>
> So... if it's only optional, that means that the general case where
> squashing is not done needs to be solved anyway. And once you have
> solved the general case, what would the point of squashing be?
> Thus, I don't find squashing useful.
>
> > For some
> > use-cases (like delicately compiled postgresql server), you can create
> > a single rpm that contains all - postgresql-server, postgresql,
> > postgresql-libs compiled in a specific way, optionally with some
> > postgresql modules pre-included, so it would be let's say time-series
> > optimized postgresql. Here it makes sense to make a single rpm from it
> > - you install that and you are all set up for your use-case.
> >
> > Then there are language stacks where you might want to build things in
> > a specific order - there nothing really needs to be squashed (or
> > certain subset can if it makes sense) but you can still use modularity
> > to easily batch-build certain rpms. If there are runtime optional
> > deps, they can be described by Recommends/Suggests.
> >
> > Basically, once a "module" (things that comes from modulemd) is built,
> > it should be put into normal repos and the "module" boundary should be
> > forgotten (unless it is a single rpm), i.e. "module" is a built-time
> > thing, at install-time we just have standard packages with standard
> > deps.
>
> Yep.
>
> The unanswered question is what mechanism would be used make sure that
> the rpms from the "module" are all installed. One option would be to
> somehow mangle rpm names, another option would be to add some kind of
> Provides/Requires, etc. But *some* mechanism is needed, because without
> that dnf would often pick other rpms.
>
> In Modularity the solution is that the rpms from the module shadow
> rpms with the same name from outside. That's probably the single
> feature of Modularity that causes the most problems.
>
> > dnf interface could be kept given that we "Stream" rpm property is
> > added. This is still a bit rough what I am saying but hopefully it
> > makes at least a bi

Re: RHEL 9 and modularity

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-06-22 at 09:19 +0200, Petr Pisar wrote:
> On Fri, Jun 19, 2020 at 02:53:56PM -0400, David Cantrell wrote:
> > 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?
> > 
> It can define a build order among packages of a module.

For that you don't actually have to design some special format. The
buildsystem should figure this out on its own. And there are such
buildsystems that do that - Open Build Service.

> It can change RPM macros in a build root (including SRPM build root).

I think this is not really good idea, but again - you don't have to
invent new format for this. Open Build Service allows you to do that in
a project configuration.

> It can use transient build dependencies (a package is built, only
> used as a build
> dependency of a consquitive package, and then dropped and never
> shipped).

Same here.

> It can build and deliver a package against multiple exclusive
> dependencies
> (e.g. for different Fedora releases).

The same thing.

> It can build a package from dist-git sources that do not depend on a
> Fedora
> release.

Again, same.

> (Teoretically you can build a module from non-RPM components; I've
> never tried
> it.)
> 
> -- Petr
> ___
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7wdP4ACgkQEV1auJxc
Hh5iiBAAsdv3yWu6y+Un2LIGFcAomRmwijA3C3aajdNXDHWO3mco/MYDukjPVMIl
FHO7xDg13ZCvxQ+AsKyVjJwRXI8ugyLatLBTO9sXLUw8LBtl36RfH/P2wXYCA6kM
kB1aWYxxBlBLuZ2cJmyYJHfXEtOFDQHz1gORIX5HyXnL/asXOPwgeh+VjYGnNMPn
FHSGCelFrW+aRU8E6vxxuqNrqFwZwXbv3ccHEJIihRMeFKoGFqfDRy/KMQFQ7zZm
NagszNoFpfAhRLEqRYaHg3GR0Kl8DYlcJCNJrXmoBdlu/nlDy2soOOzs7PiiFtuN
izdZeASITvpcBvR5h/wt52IZCAGP/G/YmSZE73LWteBZhiUBimuAzl1cAEQWfPBc
/y8/mdMXaGAKtQcWZ8ZZNMXYqpyR2Ahrl13fK2XwFBcyi6/mnCsX27KAlczhdnlS
siBzxyQW8PBvcbZdWF2XlR4W39RHH+EHdIHeeHdGauc+Oent6xObXVW9HIp/Vvkh
VH87cdSBPGiJDmZMXBWs1QqViTHzxSlyX8PI3bFxFoYA+7ZwrER75hQnKNN22Or+
Bfl5i6EHtReatUW1uxtmVODON5hZ8fcxi8v6prjDAGTUMWHHkb6f7tcR1dH42/Sf
1OLXojU8gYMuuY/ooace7zto5ByfIJT0ViUFi0eV0qvG5w053D8=
=iMXG
-END 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: protobuf update coming to rawhide

[Jaroslav Skarvada]

- Original Message -
> I prepared a protobuf update for rawhide to 3.12. It requires a rebuild
> of all dependencies and of the 55 dependencies currently 10 fail to
> rebuild. The following packages are failing:
> 
> clementine
> closure-compiler
> fawkes
> gazebo
> hidviz
> kismet
> libgadu
> mir
> mozc
> pokerth
> 
> and the failures do not seem to be protobuf related. See
> 
> https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-12/
> 
> I requested a side-tag to do the rebuilds.
> 
>   Adrian
> 

Please try to rebuild with hidviz-0.1.5-5.fc33

thanks & regards

Jaroslav
___
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: Update ejected from the push

[Alexander Ploumistos]

On Mon, Jun 22, 2020 at 10:00 AM Clement Verna  wrote:
>
> I have deployed bodhi 5.4.0 (https://github.com/fedora-infra/bodhi/releases) 
> in production today. That should fix the issue with sidetags for normal 
> releases :-)

Thank you!
I don't think I'll need to use sidetags until after the data center
move, but if something goes wrong, I'll let you know.
___
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

[Petr Pisar]

On Sat, Jun 20, 2020 at 10:32:48AM -0700, 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. ;( 
> 
An end of life of any module stream, including platform, should be stored in
PDC. But I suspect that platform is a special case.

-- Petr


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: CPE Weekly: 2020-06-21

[Qiyu Yan]

Ronaldo Mercado  于2020年6月22日周一 下午3:43写道：
>
> Thanks for your message.
>
> > See our wiki page here for more
> > information:https://docs.fedoraproject.org/en-US/cpe/
>
> I am replying because the link in your message reports "403 Forbidden"
I think that is because the data center move somehow brokes
docs.fedoraproject.org, wait for it to restore.
>
> I copy below the message from firefox.
>
> Best wishes,
>
> R Mercado
>
> Forbidden
>
> You don't have permission to access this resource.
> Apache Server at docs.fedoraproject.org Port 443
> ___
> 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

Bodhi 5.4.0 in production

[Clement Verna]

Hi all,

I have just deployed Bodhi 5.4.0 (
https://github.com/fedora-infra/bodhi/releases) in production. We were
running 5.2.2 so that deployment brings the improvement and bug fixes from
5.3.0 and 5.4.0 (see release notes)

One high level feature worth noting :

* you can now associate BZ tickets to the automatically created rawhide
updates. The bugs mentioned with the format "fix(es)|close(s)
(fedora|epel|rh|rhbz)#BUG_ID"  in the changelog will be associated to the
update and automatically closed.
More info
https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates

Also there were no changes on the client side.

Thanks all
Clément
___
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

[Petr Pisar]

On Fri, Jun 19, 2020 at 05:11:43PM -0400, Ben Cotton wrote:
> 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.
> 
This a great oportunity to speak about an implicit dependency on make covered
by RPM macros. What package should define the dependency explicitly? A spec
file that calls %make_build, or rpm package that defines the macro?

-- Petr


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: Update ejected from the push

[Clement Verna]

On Thu, 18 Jun 2020 at 18:35, Kevin Fenzi  wrote:

> On Thu, Jun 18, 2020 at 07:55:21AM +0200, Alexander Ploumistos wrote:
> > These updates, along with a couple of others I submitted 12h ago, just
> > appeared in my local mirror. Bodhi still shows everything as
> > transitioning from pending to testing and I never got a notification
> > about them having moved to testing. Side effect from the data center
> > move?
>
> Well, yes and no?
>
> The 2 updates you mentioned at the top of the thread were fixed to go in
> the next updates push:
> https://pagure.io/releng/issue/9532#comment-658452
>
> Updates pushes are at 00:14 UTC each day.
>
> So, they went out with those pushes and now have synced to your local
> mirror. :)
>
> The underlying sidetag issues are being worked on.
> I'm not 100% sure of the status...
>

I have deployed bodhi 5.4.0 (https://github.com/fedora-infra/bodhi/releases)
in production today. That should fix the issue with sidetags for normal
releases :-)


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

[Bug 1849262] perl-Net-IPv6Addr-1.01 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1849262

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|iarn...@gmail.com,  |
   |sindr...@fedoraproject.org  |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-de...@lists.fedoraproject.org

RE: CPE Weekly: 2020-06-21

[Ronaldo Mercado]

Thanks for your message.

> See our wiki page here for more
> information:https://docs.fedoraproject.org/en-US/cpe/

I am replying because the link in your message reports "403 Forbidden"

I copy below the message from firefox.

Best wishes,

R Mercado

Forbidden

You don't have permission to access this resource.
Apache Server at docs.fedoraproject.org Port 443
___
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

[Petr Pisar]

On Fri, Jun 19, 2020 at 02:53:56PM -0400, David Cantrell wrote:
> 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?
> 
It can define a build order among packages of a module.
It can change RPM macros in a build root (including SRPM build root).
It can use transient build dependencies (a package is built, only used as a 
build
dependency of a consquitive package, and then dropped and never shipped).
It can build and deliver a package against multiple exclusive dependencies
(e.g. for different Fedora releases).
It can build a package from dist-git sources that do not depend on a Fedora
release.
(Teoretically you can build a module from non-RPM components; I've never tried
it.)

-- Petr


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