Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

[Ahmed Almeleh]

I'm interested and am keen to learn more about how it all works.

On Fri, 2 Dec 2022 at 18:07, Michael Dawson  wrote:

> Great to see all the interest so far. Will continue to point people to
> this thread to collect those who are interested in being involved and will
> look to get the SIG rolling early in the new year.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

[ivan]

> As Web Assembly (WASM) gains momentum we’d like to create a SIG as a place to 
> collaborate
> to ensure that Fedora is a great platform to both build and run WASM 
> workloads. This
> includes looking at the toolchains needed to build WASM as a target and the 
> runtimes
> needed to run WASM. It will provide a place to bring together efforts across 
> different
> ecosystems (nodejs, rust, compiler toolchains, etc.) as well as a place where 
> people can
> provide self-help when building and running WASM workloads.
> 
> If you are interested in a WASM Sig please let us know.

I'm interested!

Ivan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump

[Jiri Kucera]

Yes, builds in [1] were built with the `f38-build-side-60497` side tag. In
[1] there are two errors that were not here in time I hit the submit button
(maybe I should wait a bit longer):
* `nothing provides libqgpgme.so.7 needed by
kdepim-addons-22.08.3-1.fc38.i686` - this one was
  caused by not building `kdepim-addons` on `i686` since missing
`libphonenumber` on `i686`.
  `libphonenumber` is not built for `i686` anymore due to `ExclusiveArch:
%{java_arches}`. This
  can be fixed by skipping building the Java binding for `i686` only.
* ```
  Undeclared file conflicts:
  kleopatra-*.i686 provides ... which is also provided by kleopatra-*.x86_64
  ...
  kmail-*.i686 provides ... which is also provided by kmail-*.x86_64
  ...
  ```
  These must have appeared also in the update before, but I cannot find
`rpmdeplint` tests
  here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e8d23a026e

I submitted [2] approx. 22h after [1] became stable. Have no idea why the
builds from pre-[1] rawhide were picked up. However, `rpmdeplint`
repoclosure failures are happening only on `i686` so maybe this is somehow
connected with `kdepim-addons` not built for `i686`.

Regards and sorry for the chaos,
Jiri

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3

On Fri, Dec 2, 2022 at 11:54 AM Miro Hrončok  wrote:

> On 02. 12. 22 1:46, Adam Williamson wrote:
> > On Wed, 2022-11-30 at 13:59 +0100, Jiri Kucera wrote:
> >> Thanks for the reminder Petr. I will do the rebase in rawhide only then.
> >
> > Thanks for taking care of these dependencies and announcing the bump.
> >
> > For extra bonus points :D, if it's not too much trouble, it would be
> > great if you could do this on a side tag in future - yes, even for
> > Rawhide. Without a side tag and combined update, the openQA tests for
> > the gpgme update fail:
> >
> https://openqa.stg.fedoraproject.org/tests/overview?version=38&groupid=2&build=Update-FEDORA-2022-603eea89a3&distri=fedora
> > if the gpgme bump and all dependent rebuilds were in the same update,
> > the tests would pass (assuming nothing's actually broken).
> >
> > Right now we're not gating Rawhide updates on test failures, but I do
> > check them all, so I had to make sure all the rebuilds had actually
> > been done, then add comments noting the tests need to be re-run after
> > the next Rawhide compose, then remember to re-run them so all that ugly
> > red ink goes away :D If/when we do start gating Rawhide on openQA
> > failures, this update would be blocked by gating.
>
> Interesting. I saw
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b where side
> tag
> was used.
>
> Later, there was
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
> which only changed a small portion from the package.
>
> Why would the tests fails for the second update?
>
> --
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump

[Jiri Kucera]

Hmm, concerning `libphonenumber` there is no Java binding, only the C++
port of the original Java library. Moreover, nothing Java-related is
distributed in the RPMs. That means that `BuildRequires: java-devel` is
redundant here. I will try to do a scratch build.

Regards,
Jiri

On Fri, Dec 2, 2022 at 9:25 PM Jiri Kucera  wrote:

> Yes, builds in [1] were built with the `f38-build-side-60497` side tag. In
> [1] there are two errors that were not here in time I hit the submit button
> (maybe I should wait a bit longer):
> * `nothing provides libqgpgme.so.7 needed by
> kdepim-addons-22.08.3-1.fc38.i686` - this one was
>   caused by not building `kdepim-addons` on `i686` since missing
> `libphonenumber` on `i686`.
>   `libphonenumber` is not built for `i686` anymore due to `ExclusiveArch:
> %{java_arches}`. This
>   can be fixed by skipping building the Java binding for `i686` only.
> * ```
>   Undeclared file conflicts:
>   kleopatra-*.i686 provides ... which is also provided by
> kleopatra-*.x86_64
>   ...
>   kmail-*.i686 provides ... which is also provided by kmail-*.x86_64
>   ...
>   ```
>   These must have appeared also in the update before, but I cannot find
> `rpmdeplint` tests
>   here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e8d23a026e
>
> I submitted [2] approx. 22h after [1] became stable. Have no idea why the
> builds from pre-[1] rawhide were picked up. However, `rpmdeplint`
> repoclosure failures are happening only on `i686` so maybe this is somehow
> connected with `kdepim-addons` not built for `i686`.
>
> Regards and sorry for the chaos,
> Jiri
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b
> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
>
> On Fri, Dec 2, 2022 at 11:54 AM Miro Hrončok  wrote:
>
>> On 02. 12. 22 1:46, Adam Williamson wrote:
>> > On Wed, 2022-11-30 at 13:59 +0100, Jiri Kucera wrote:
>> >> Thanks for the reminder Petr. I will do the rebase in rawhide only
>> then.
>> >
>> > Thanks for taking care of these dependencies and announcing the bump.
>> >
>> > For extra bonus points :D, if it's not too much trouble, it would be
>> > great if you could do this on a side tag in future - yes, even for
>> > Rawhide. Without a side tag and combined update, the openQA tests for
>> > the gpgme update fail:
>> >
>> https://openqa.stg.fedoraproject.org/tests/overview?version=38&groupid=2&build=Update-FEDORA-2022-603eea89a3&distri=fedora
>> > if the gpgme bump and all dependent rebuilds were in the same update,
>> > the tests would pass (assuming nothing's actually broken).
>> >
>> > Right now we're not gating Rawhide updates on test failures, but I do
>> > check them all, so I had to make sure all the rebuilds had actually
>> > been done, then add comments noting the tests need to be re-run after
>> > the next Rawhide compose, then remember to re-run them so all that ugly
>> > red ink goes away :D If/when we do start gating Rawhide on openQA
>> > failures, this update would be blocked by gating.
>>
>> Interesting. I saw
>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b where
>> side tag
>> was used.
>>
>> Later, there was
>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
>> which only changed a small portion from the package.
>>
>> Why would the tests fails for the second update?
>>
>> --
>> 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
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Adam Williamson]

So there's this CI ticket ATM[0] about whether the environment in which
CI tests are run should or should not include and update from the
'buildroot' repo, which contains both:

1. Packages that have been pushed stable since the last time a compose
succeeded (for Rawhide that's a Rawhide compose, for Branched it's a
Branched compose, for stable releases it's an updates compose)
2. Packages that have active buildroot overrides

Thinking about this reminded me again why buildroot overrides are such
a bad idea:
https://pagure.io/fedora-ci/general/issue/376#comment-830638

Buildroot overrides have unpredictable consequences for builds, updates
*and* tests. I really feel like we should consider disallowing them and
requiring all rebases to be done using side tags. Side tags are a
*much* better design that avoids the problem of packages unexpectedly
being built against a buildroot override somebody else submitted, and
means test systems aren't stuck in a bind of not really knowing for
sure what other packages should be installed when testing any given
package.

What does everyone else think? Has the time come? Or is there more we
need to do to make side tags usable for all cases before getting rid of
overrides?

[0]: https://pagure.io/fedora-ci/general/issue/376
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

[Ivan Font]

> As Web Assembly (WASM) gains momentum we’d like to create a SIG as a place to 
> collaborate
> to ensure that Fedora is a great platform to both build and run WASM 
> workloads. This
> includes looking at the toolchains needed to build WASM as a target and the 
> runtimes
> needed to run WASM. It will provide a place to bring together efforts across 
> different
> ecosystems (nodejs, rust, compiler toolchains, etc.) as well as a place where 
> people can
> provide self-help when building and running WASM workloads.
> 
> If you are interested in a WASM Sig please let us know.

I am interested as well!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Richard Shaw]

On Fri, Dec 2, 2022 at 3:30 PM Adam Williamson 
wrote:

>
> What does everyone else think? Has the time come? Or is there more we
> need to do to make side tags usable for all cases before getting rid of
> overrides?
>

I wasn't aware of the CI issues so that seems like the last nail in the
coffin. The only time I've used one recently is because I forgot about a
package dependency and it was easier to create a buildroot override than
look up how to re-tag the build into a side tag.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Fabio Valentini]

On Fri, Dec 2, 2022 at 11:13 PM Richard Shaw  wrote:
>
> On Fri, Dec 2, 2022 at 3:30 PM Adam Williamson  
> wrote:
>>
>>
>> What does everyone else think? Has the time come? Or is there more we
>> need to do to make side tags usable for all cases before getting rid of
>> overrides?
>
>
> I wasn't aware of the CI issues so that seems like the last nail in the 
> coffin. The only time I've used one recently is because I forgot about a 
> package dependency and it was easier to create a buildroot override than look 
> up how to re-tag the build into a side tag.

That has been my experience as well: Use on-demand side-tags for
everything, and use buildroot overrides only when using a side-tag
would be very inconvenient (i.e. tagging in builds that were already
submitted as another update into another side tag). But I don't think
buildroot overrides are really *necessary* for any workflows anymore,
either ...

Not sure if we should turn them off entirely, but we could restrict
their use somewhat? For example, only allow people in "releng" or "qa"
groups to file them.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Maxwell G via devel]

On Fri Dec 2, 2022 at 13:30 -0800, Adam Williamson wrote:
> What does everyone else think? Has the time come? Or is there more we
> need to do to make side tags usable for all cases before getting rid of
> overrides?

-1. For many use cases, side tags are the correct solution and buildroot
overrides should not be used. However, there are occasions where they are still
useful. If people are improperly using buildroot overrides and breaking the
buildroot, the correct solution is education and documentation, not banning
them entirely. Examples:

1. There is a Go compiler release that has patches for a CVE (i.e. almost every
   Go release ). I create buildroot overrides so all new builds are able to
   immediately start using it.

2. The same thing above but with other Go libraries that are statically linked
   into Go binaries.

3. There is a bug in macros that break builds. The fix should be available in
   the buildroot for all new builds immediately.

4. Some other buildtime only dependency update provides a bugfix that is needed
   for packages that BuildRequire it.


On Fri Dec 2, 2022 at 23:21 +0100, Fabio Valentini wrote:
> Not sure if we should turn them off entirely, but we could restrict
> their use somewhat? For example, only allow people in "releng" or "qa"
> groups to file them.

I'd prefer not to have to bother releng every time I need to do this.

--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Kalev Lember]

On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson 
wrote:

> So there's this CI ticket ATM[0] about whether the environment in which
> CI tests are run should or should not include and update from the
> 'buildroot' repo, which contains both:
>
> 1. Packages that have been pushed stable since the last time a compose
> succeeded (for Rawhide that's a Rawhide compose, for Branched it's a
> Branched compose, for stable releases it's an updates compose)
> 2. Packages that have active buildroot overrides
>
> Thinking about this reminded me again why buildroot overrides are such
> a bad idea:
> https://pagure.io/fedora-ci/general/issue/376#comment-830638
>
> Buildroot overrides have unpredictable consequences for builds, updates
> *and* tests. I really feel like we should consider disallowing them and
> requiring all rebases to be done using side tags. Side tags are a
> *much* better design that avoids the problem of packages unexpectedly
> being built against a buildroot override somebody else submitted, and
> means test systems aren't stuck in a bind of not really knowing for
> sure what other packages should be installed when testing any given
> package.
>
> What does everyone else think? Has the time come? Or is there more we
> need to do to make side tags usable for all cases before getting rid of
> overrides?
>

I would say that side tags are almost always the correct tool for ABI
rebuilds. I imagine people who submit global buildroot overrides to handle
a library soname bump are almost always doing it because they haven't
learned the "new" ways of doing it.

I'd go as far as to say that anyone who does ABI rebuilds using global
buildroot overrides are doing it wrong.

However, having said that, I also find buildroot overrides useful. Some
examples:

1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new
version through the freeze, but that includes a library soname bump.

What I would do in that case is submit the GNOME megaupdate to Bodhi, and
also submit the library as a buildroot override to ensure that nothing can
build against the old soname -- I am fairly confident that the GNOME
megaupdate, together with the soname bump makes it to stable first.

2) I need to do a container build and include a new CVE fix (as it's
critical and we need to get fixes out ASAP), but that package build to
include in the container is only in updates-testing.

What I'd do in this case is to submit a buildroot override because
everything that's overridden gets included in container builds. After my
container build is done I'd expire the buildroot override.

3) We've had some "fun" issues with sysprof symbols leaking out from the
GTK stack into other libraries consuming it. This has caused subtle ABI
issues and when working on a fix and to make sure no package can build
against the "wrong" GTK version, I've used buildroot overrides.

4) Compiler issues, with compilers producing broken code.

To test the fixes and make sure packages start using the new fixed versions
ASAP, a buildroot override is often useful.

I could continue with the list but I think you get my point that there are
some cases where it's useful :) However I'd never use buildroot overrides
for soname bump rebuilds; that's what side tags are good for.

Maybe doing occasional blog posts and teaching maintainers how to do multi
package updates would be helpful? Not sure what else we could do to help
improve the situation here.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Review Request: ImageMagick7

[Sérgio Basto]

Hi,

I think it's important to bring ImageMagick 7 to Fedora, and it should
have been done a long time ago .
The proposal now is to keep ImageMagick 6 and make a new package with
ImageMagick 7 , when we have all applications use only ImageMagick 7,
we move the sources from ImageMagick7 to ImageMagick

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

Please help me to review it 

Thank you, 
-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Miro Hrončok]

On 03. 12. 22 0:14, Kalev Lember wrote:
On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson > wrote:


So there's this CI ticket ATM[0] about whether the environment in which
CI tests are run should or should not include and update from the
'buildroot' repo, which contains both:

1. Packages that have been pushed stable since the last time a compose
succeeded (for Rawhide that's a Rawhide compose, for Branched it's a
Branched compose, for stable releases it's an updates compose)
2. Packages that have active buildroot overrides

Thinking about this reminded me again why buildroot overrides are such
a bad idea:
https://pagure.io/fedora-ci/general/issue/376#comment-830638


Buildroot overrides have unpredictable consequences for builds, updates
*and* tests. I really feel like we should consider disallowing them and
requiring all rebases to be done using side tags. Side tags are a
*much* better design that avoids the problem of packages unexpectedly
being built against a buildroot override somebody else submitted, and
means test systems aren't stuck in a bind of not really knowing for
sure what other packages should be installed when testing any given
package.

What does everyone else think? Has the time come? Or is there more we
need to do to make side tags usable for all cases before getting rid of
overrides?


I would say that side tags are almost always the correct tool for ABI rebuilds. 
I imagine people who submit global buildroot overrides to handle a library 
soname bump are almost always doing it because they haven't learned the "new" 
ways of doing it.


I'd go as far as to say that anyone who does ABI rebuilds using global 
buildroot overrides are doing it wrong.


However, having said that, I also find buildroot overrides useful. Some 
examples:

1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new 
version through the freeze, but that includes a library soname bump.


What I would do in that case is submit the GNOME megaupdate to Bodhi, and also 
submit the library as a buildroot override to ensure that nothing can build 
against the old soname -- I am fairly confident that the GNOME megaupdate, 
together with the soname bump makes it to stable first.


2) I need to do a container build and include a new CVE fix (as it's critical 
and we need to get fixes out ASAP), but that package build to include in the 
container is only in updates-testing.


What I'd do in this case is to submit a buildroot override because everything 
that's overridden gets included in container builds. After my container build 
is done I'd expire the buildroot override.


3) We've had some "fun" issues with sysprof symbols leaking out from the GTK 
stack into other libraries consuming it. This has caused subtle ABI issues and 
when working on a fix and to make sure no package can build against the "wrong" 
GTK version, I've used buildroot overrides.


4) Compiler issues, with compilers producing broken code.

To test the fixes and make sure packages start using the new fixed versions 
ASAP, a buildroot override is often useful.


I could continue with the list but I think you get my point that there are some 
cases where it's useful :) However I'd never use buildroot overrides for soname 
bump rebuilds; that's what side tags are good for.


Maybe doing occasional blog posts and teaching maintainers how to do multi 
package updates would be helpful? Not sure what else we could do to help 
improve the situation here.


I am pretty much with Kalev on this.

The only way to land ABI (or similar) rebuilds should be side tags, but I still 
use overrides for other stuff.


E.g. when I need a change in an RPM macro package to make other packages build 
properly. I see no reason for creating a single bodhi update with the RPM macro 
package and couple packages that were blocked on that update.


My latest buidlroot overrides were:

https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-34
See 
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54#comment-121866


https://bodhi.fedoraproject.org/overrides/python-setuptools-59.6.0-3.fc36
https://bodhi.fedoraproject.org/overrides/python-pip-21.3.1-4.fc36
https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3.11-5.fc37
To workaround https://pagure.io/fedora-ci/general/issue/240

--
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
Do not reply to spam

Re: Review Request: ImageMagick7

[Richard Shaw]

On Fri, Dec 2, 2022 at 5:31 PM Sérgio Basto  wrote:

> Hi,
>
> I think it's important to bring ImageMagick 7 to Fedora, and it should
> have been done a long time ago .
> The proposal now is to keep ImageMagick 6 and make a new package with
> ImageMagick 7 , when we have all applications use only ImageMagick 7,
> we move the sources from ImageMagick7 to ImageMagick
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2150206


Wouldn't the correct way to handle this be to create an ImageMagick6 compat
package and update the main package to version 7?

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Adam Williamson]

On Sat, 2022-12-03 at 00:14 +0100, Kalev Lember wrote:
> On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson 
> wrote:
> 
> > So there's this CI ticket ATM[0] about whether the environment in which
> > CI tests are run should or should not include and update from the
> > 'buildroot' repo, which contains both:
> > 
> > 1. Packages that have been pushed stable since the last time a compose
> > succeeded (for Rawhide that's a Rawhide compose, for Branched it's a
> > Branched compose, for stable releases it's an updates compose)
> > 2. Packages that have active buildroot overrides
> > 
> > Thinking about this reminded me again why buildroot overrides are such
> > a bad idea:
> > https://pagure.io/fedora-ci/general/issue/376#comment-830638
> > 
> > Buildroot overrides have unpredictable consequences for builds, updates
> > *and* tests. I really feel like we should consider disallowing them and
> > requiring all rebases to be done using side tags. Side tags are a
> > *much* better design that avoids the problem of packages unexpectedly
> > being built against a buildroot override somebody else submitted, and
> > means test systems aren't stuck in a bind of not really knowing for
> > sure what other packages should be installed when testing any given
> > package.
> > 
> > What does everyone else think? Has the time come? Or is there more we
> > need to do to make side tags usable for all cases before getting rid of
> > overrides?
> > 
> 
> I would say that side tags are almost always the correct tool for ABI
> rebuilds. I imagine people who submit global buildroot overrides to handle
> a library soname bump are almost always doing it because they haven't
> learned the "new" ways of doing it.
> 
> I'd go as far as to say that anyone who does ABI rebuilds using global
> buildroot overrides are doing it wrong.
> 
> However, having said that, I also find buildroot overrides useful. Some
> examples:
> 
> 1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new
> version through the freeze, but that includes a library soname bump.
> 
> What I would do in that case is submit the GNOME megaupdate to Bodhi, and
> also submit the library as a buildroot override to ensure that nothing can
> build against the old soname -- I am fairly confident that the GNOME
> megaupdate, together with the soname bump makes it to stable first.
> 
> 2) I need to do a container build and include a new CVE fix (as it's
> critical and we need to get fixes out ASAP), but that package build to
> include in the container is only in updates-testing.
> 
> What I'd do in this case is to submit a buildroot override because
> everything that's overridden gets included in container builds. After my
> container build is done I'd expire the buildroot override.
> 
> 3) We've had some "fun" issues with sysprof symbols leaking out from the
> GTK stack into other libraries consuming it. This has caused subtle ABI
> issues and when working on a fix and to make sure no package can build
> against the "wrong" GTK version, I've used buildroot overrides.
> 
> 4) Compiler issues, with compilers producing broken code.
> 
> To test the fixes and make sure packages start using the new fixed versions
> ASAP, a buildroot override is often useful.
> 
> I could continue with the list but I think you get my point that there are
> some cases where it's useful :) However I'd never use buildroot overrides
> for soname bump rebuilds; that's what side tags are good for.

Well, hmm.

The examples you provide are definitely interesting. They all
essentially boil down to, well, "I know exactly how this process works
and I'm gonna take advantage of that to achieve the right outcome
behind the scenes". Which, you know, we have a lot of stuff like that,
but it can be difficult to work with in ways like this.

I do see the value in your use of the buildroot in those cases, but I
can't help thinking there must be a *better* way. But, I'm not sure
I've thought of a practical one yet. All the ones that came off the top
of my head turn out to be silly after thirty seconds thinking about it.
Ugh.

Hum. I suppose if there really were only uses of the buildroot like the
above...then...it should be *fairly* safe for test systems to always
test against the buildroot repo contents. Uh. Maybe. I don't love it,
but I don't know what's better.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Neal Gompa]

On Fri, Dec 2, 2022 at 6:35 PM Richard Shaw  wrote:
>
> On Fri, Dec 2, 2022 at 5:31 PM Sérgio Basto  wrote:
>>
>> Hi,
>>
>> I think it's important to bring ImageMagick 7 to Fedora, and it should
>> have been done a long time ago .
>> The proposal now is to keep ImageMagick 6 and make a new package with
>> ImageMagick 7 , when we have all applications use only ImageMagick 7,
>> we move the sources from ImageMagick7 to ImageMagick
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2150206
>
>
> Wouldn't the correct way to handle this be to create an ImageMagick6 compat 
> package and update the main package to version 7?
>

Yes, that's the correct way to do it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Sérgio Basto]

On Fri, 2022-12-02 at 17:34 -0600, Richard Shaw wrote:
> On Fri, Dec 2, 2022 at 5:31 PM Sérgio Basto 
> wrote:
> > Hi,
> > 
> > I think it's important to bring ImageMagick 7 to Fedora, and it
> > should
> > have been done a long time ago .
> > The proposal now is to keep ImageMagick 6 and make a new package
> > with
> > ImageMagick 7 , when we have all applications use only ImageMagick
> > 7,
> > we move the sources from ImageMagick7 to ImageMagick
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2150206
> > 
> 
> 
> Wouldn't the correct way to handle this be to create an ImageMagick6
> compat package and update the main package to version 7?

In this case, I don't think is a good idea, mainly because will give a
lot more work and even so could break things, I think we
not want change ImageMagick name, specially in epel 8 and 9, like for
example python and python3 case, maybe for epel 10 we could have
ImageMagick6 compat , IMO. 



> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Fedora Sway Spin (Self-Contained Change proposal)

[Philip Rhoades via devel]

Major,


On 2022-12-03 02:27, Major Hayden wrote:

On 12/1/22 11:35, Ben Cotton wrote:

== Detailed Description ==
Fedora Window Manager spins greatly benefit users who enjoy a minimal
desktop. Sway is beginning to become well polished and is continuing
to gain traction from the community. Fedora particularly has a
first-class Wayland experience making an even more compelling use case
for having a Wayland window manager spin.


Great idea! I've been on Sway for a few Fedora releases and it's been a
pleasure to use. I also like keeping a fairly minimal system and Sway
makes that a little easier.



+1



For those reasons, we propose to create a Sway spin and an ostree one,
called `Sericea`.



That _could_ be interesting for me in the future . .



What made you choose the name? (Just curious.)

I had to go look it up[0].


The goal of both spins would be to create a turnkey environment to
enjoy Fedora and Sway functionally and beautifully.
To achieve this, we plan to put in those spins the minimum amount of
packages to accomplish the stated goal. [[User:alebastr| Aleksei
Bavshin]] has begun an
[https://src.fedoraproject.org/rpms/sway/pull-request/12 RFC] for the
`sway` source package that would extend it by creating three
sub-packages with Fedora's default Sway configuration.


Good idea on the splitting. I believe this was done recently for i3, 
too.



+1



== Feedback ==
Feedback has been low at the moment.
We have seen wildly different feedback, from people saying they liked
the idea and would use it to others who do not see the value of it and
will probably not use it.
Some commenters highlighted that this isn't worthwhile for them as
they would prefer to have Gnome installed alongside Sway.



-1



There have
also been comments that some users like having a minimal package set
that only includes Sway and don't want a two-step process to get to
their environment, which would be the situation if they install a spin
that is not Sway and then have to install Sway on top.



+1



I've installed Sway several times through the two-step process and
although it's not too difficult, it's not easy for new users. This 
means
each user must determine which Sway packages and related extras 
(perhaps
mako, wofi, etc) that they want to add. There's a great opportunity 
here

for people who know a lot about Sway to create an awesome installation
experience as well as a good Sway setup after the reboot.



+1 Minimal Sway + easy package add for experts . .


The two-step process leaves me to make a lot of those decisions and 
look

up which extra applications I need to add.


== Benefit to Fedora ==

Like the introduction of the i3 Spin, this change benefits end-users
who run Fedora on a desktop or laptop, particularly low-end
consumer-grade hardware.



Yes! (for my old Zenbook . .)



A Sway Spin would provide a better initial installation experience for
Fedora users installing Sway for the first time. Currently, end-users
who wish to use Sway on Fedora must install another Edition or Spin of
Fedora, then install the Sway window manager (and related packages)
separately. Also, at the moment, the process is not documented in
Fedora documentation, forcing the user to use an external guide or
tutorial.



It was only a little annoying but it could be perfect with a Minimal 
Sway install.




Additionally, this "two-step" (first install Fedora, then install Sway
on top of it) method adds unnecessary packages to the user's system,



Exactly!



particularly if the end-user does not wish to use another desktop
environment. One of Fedora's foundations is being "First".
We believe that, in this situation, being committed to being "First"
means pushing the boundaries of Sway and Wayland by shipping the first
Fedora Spin that is based on a Wayland-only Window Manager.



+2 !



Well said. Thanks for proposing this change. 👏🏻



+1

Phil.

--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

[Philip Rhoades via devel]

Michael,


On 2022-12-03 05:06, Michael Dawson wrote:

Great to see all the interest so far. Will continue to point people to
this thread to collect those who are interested in being involved and
will look to get the SIG rolling early in the new year.



Excellent! - thanks!

P.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Neal Gompa]

On Fri, Dec 2, 2022 at 10:29 PM Sérgio Basto  wrote:
>
> On Fri, 2022-12-02 at 17:34 -0600, Richard Shaw wrote:
>
> On Fri, Dec 2, 2022 at 5:31 PM Sérgio Basto  wrote:
>
> Hi,
>
> I think it's important to bring ImageMagick 7 to Fedora, and it should
> have been done a long time ago .
> The proposal now is to keep ImageMagick 6 and make a new package with
> ImageMagick 7 , when we have all applications use only ImageMagick 7,
> we move the sources from ImageMagick7 to ImageMagick
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2150206
>
>
> Wouldn't the correct way to handle this be to create an ImageMagick6 compat 
> package and update the main package to version 7?
>
>
> In this case, I don't think is a good idea, mainly because will give a lot 
> more work and even so could break things, I think we not want change 
> ImageMagick name, specially in epel 8 and 9, like for example python and 
> python3 case, maybe for epel 10 we could have ImageMagick6 compat , IMO.
>

But that change has to happen *somewhere*. Fedora is it. If you don't
do it now, then we'll *never* get to do it.

And one of the purposes of Fedora is to be "First" and do "Features".
Make a Fedora Linux 38 Change to do it if you must.

But the approach you're going for is not good, because it doesn't
drive us to move things forward. There's usually only a drive to
upgrade when someone creates a forcing function for it.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Sérgio Basto]

On Fri, 2022-12-02 at 22:41 -0500, Neal Gompa wrote:
> On Fri, Dec 2, 2022 at 10:29 PM Sérgio Basto 
> wrote:
> > 
> > On Fri, 2022-12-02 at 17:34 -0600, Richard Shaw wrote:
> > 
> > On Fri, Dec 2, 2022 at 5:31 PM Sérgio Basto 
> > wrote:
> > 
> > Hi,
> > 
> > I think it's important to bring ImageMagick 7 to Fedora, and it
> > should
> > have been done a long time ago .
> > The proposal now is to keep ImageMagick 6 and make a new package
> > with
> > ImageMagick 7 , when we have all applications use only ImageMagick
> > 7,
> > we move the sources from ImageMagick7 to ImageMagick
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2150206
> > 
> > 
> > Wouldn't the correct way to handle this be to create an
> > ImageMagick6 compat package and update the main package to version
> > 7?
> > 
> > 
> > In this case, I don't think is a good idea, mainly because will
> > give a lot more work and even so could break things, I think we not
> > want change ImageMagick name, specially in epel 8 and 9, like for
> > example python and python3 case, maybe for epel 10 we could have
> > ImageMagick6 compat , IMO.
> > 
> 
> But that change has to happen *somewhere*. Fedora is it. If you don't
> do it now, then we'll *never* get to do it.
> 
> And one of the purposes of Fedora is to be "First" and do "Features".
> Make a Fedora Linux 38 Change to do it if you must.
> 
> But the approach you're going for is not good, because it doesn't
> drive us to move things forward. There's usually only a drive to
> upgrade when someone creates a forcing function for it.
> 

Sometimes forcing moving forward can be a huge mistake, IMO.
In this case we also want bring IM-7 to epel(s) quickly. After things
are stabilized, we may think in "forcing" ImageMagick-7.

BTW we already try upgrade to Imagemagick-7 in Fedora 26 / 27 and
didn't went well 

https://bodhi.fedoraproject.org/updates/?search=ImageMagick&releases=F27&releases=F26
 

> 
> -- 
> 真実はいつも一つ！/ 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Neal Gompa]

On Fri, Dec 2, 2022 at 11:55 PM Sérgio Basto  wrote:
>
> On Fri, 2022-12-02 at 22:41 -0500, Neal Gompa wrote:
> > On Fri, Dec 2, 2022 at 10:29 PM Sérgio Basto 
> > wrote:
> > >
> > > On Fri, 2022-12-02 at 17:34 -0600, Richard Shaw wrote:
> > >
> > > On Fri, Dec 2, 2022 at 5:31 PM Sérgio Basto 
> > > wrote:
> > >
> > > Hi,
> > >
> > > I think it's important to bring ImageMagick 7 to Fedora, and it
> > > should
> > > have been done a long time ago .
> > > The proposal now is to keep ImageMagick 6 and make a new package
> > > with
> > > ImageMagick 7 , when we have all applications use only ImageMagick
> > > 7,
> > > we move the sources from ImageMagick7 to ImageMagick
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2150206
> > >
> > >
> > > Wouldn't the correct way to handle this be to create an
> > > ImageMagick6 compat package and update the main package to version
> > > 7?
> > >
> > >
> > > In this case, I don't think is a good idea, mainly because will
> > > give a lot more work and even so could break things, I think we not
> > > want change ImageMagick name, specially in epel 8 and 9, like for
> > > example python and python3 case, maybe for epel 10 we could have
> > > ImageMagick6 compat , IMO.
> > >
> >
> > But that change has to happen *somewhere*. Fedora is it. If you don't
> > do it now, then we'll *never* get to do it.
> >
> > And one of the purposes of Fedora is to be "First" and do "Features".
> > Make a Fedora Linux 38 Change to do it if you must.
> >
> > But the approach you're going for is not good, because it doesn't
> > drive us to move things forward. There's usually only a drive to
> > upgrade when someone creates a forcing function for it.
> >
>
> Sometimes forcing moving forward can be a huge mistake, IMO.
> In this case we also want bring IM-7 to epel(s) quickly. After things
> are stabilized, we may think in "forcing" ImageMagick-7.
>

No, we don't. We want to only bring things to EPEL once they're good in Fedora.

> BTW we already try upgrade to Imagemagick-7 in Fedora 26 / 27 and
> didn't went well
>
> https://bodhi.fedoraproject.org/updates/?search=ImageMagick&releases=F27&releases=F26
>

That was not done properly. It wasn't done as a proper upgrade in
Rawhide. There was no effort done to reconcile all the reverse
dependencies, and there was no announcement of the soname bump. That
was why it was reverted.

Once it's good and done in Fedora, we can also announce an upgrade for
EPEL and introduce a compat package for IM6 at the same time. Those kinds of
things are not a problem to do there if well-coordinated with the EPEL
Steering Committee.







--
真実はいつも一つ！/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Benson Muite]

On 12/2/22 14:04, Vít Ondruch wrote:


Dne 02. 12. 22 v 8:00 Benson Muite napsal(a):



- rpms/ruby-ncurses

Taken



Why? It does not deserve to live, at least in its current (abandoned and 
deprecated) form.



Thanks for the warning. Orphaned it.


Vít


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Sérgio Basto]

On Sat, 2022-12-03 at 00:12 -0500, Neal Gompa wrote:
> On Fri, Dec 2, 2022 at 11:55 PM Sérgio Basto 
> wrote:
> > 
> > On Fri, 2022-12-02 at 22:41 -0500, Neal Gompa wrote:
> > > On Fri, Dec 2, 2022 at 10:29 PM Sérgio Basto 
> > > wrote:
> > > > 
> > > > On Fri, 2022-12-02 at 17:34 -0600, Richard Shaw wrote:
> > > > 
> > > > On Fri, Dec 2, 2022 at 5:31 PM Sérgio Basto 
> > > > wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > I think it's important to bring ImageMagick 7 to Fedora, and it
> > > > should
> > > > have been done a long time ago .
> > > > The proposal now is to keep ImageMagick 6 and make a new
> > > > package
> > > > with
> > > > ImageMagick 7 , when we have all applications use only
> > > > ImageMagick
> > > > 7,
> > > > we move the sources from ImageMagick7 to ImageMagick
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=2150206
> > > > 
> > > > 
> > > > Wouldn't the correct way to handle this be to create an
> > > > ImageMagick6 compat package and update the main package to
> > > > version
> > > > 7?
> > > > 
> > > > 
> > > > In this case, I don't think is a good idea, mainly because will
> > > > give a lot more work and even so could break things, I think we
> > > > not
> > > > want change ImageMagick name, specially in epel 8 and 9, like
> > > > for
> > > > example python and python3 case, maybe for epel 10 we could
> > > > have
> > > > ImageMagick6 compat , IMO.
> > > > 
> > > 
> > > But that change has to happen *somewhere*. Fedora is it. If you
> > > don't
> > > do it now, then we'll *never* get to do it.
> > > 
> > > And one of the purposes of Fedora is to be "First" and do
> > > "Features".
> > > Make a Fedora Linux 38 Change to do it if you must.
> > > 
> > > But the approach you're going for is not good, because it doesn't
> > > drive us to move things forward. There's usually only a drive to
> > > upgrade when someone creates a forcing function for it.
> > > 
> > 
> > Sometimes forcing moving forward can be a huge mistake, IMO.
> > In this case we also want bring IM-7 to epel(s) quickly. After
> > things
> > are stabilized, we may think in "forcing" ImageMagick-7.
> > 
> 
> No, we don't. We want to only bring things to EPEL once they're good
> in Fedora.

and ImageMagick-7 isn't good for epel ? what is the point here ? 

> 
> > BTW we already try upgrade to Imagemagick-7 in Fedora 26 / 27 and
> > didn't went well
> > 
> > https://bodhi.fedoraproject.org/updates/?search=ImageMagick&releases=F27&releases=F26
> > 
> 
> That was not done properly. It wasn't done as a proper upgrade in
> Rawhide. There was no effort done to reconcile all the reverse
> dependencies, and there was no announcement of the soname bump. That
> was why it was reverted.
> 
> Once it's good and done in Fedora, we can also announce an upgrade
> for
> EPEL and introduce a compat package for IM6 at the same time. Those
> kinds of
> things are not a problem to do there if well-coordinated with the
> EPEL
> Steering Committee.


As I'm trying explain, ImageMagick is not a package with few
dependencies, we have php, perl extensions etc for example and what you
are proposing will break in a lot of places including third-party repos
and I won't have time to respond it in time , we need a more smooth
transaction (IMO) .



> 
> 
> 
> 
> 
> 
> --
> 真実はいつも一つ！/ 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: wlroots 0.16 update announcement

[Aleksei Bavshin]

On 11/27/22 14:51, Aleksei Bavshin wrote:

Greetings,

Sometime within the next week, I'll be updating wlroots in rawhide to 
0.16.0[1] and sway to the latest release candidate. As usual, the update 
contains API/ABI breaking changes and soname will be bumped to 
libwlroots.so.11. wlroots0.15 compatibility package will be introduced 
in the same side-tag.


No breakages are expected and no action is required from the maintainers 
of dependent packages.


I'll send another notice with a side-tag id to unblock the updates that 
already require 0.16 (currently only labwc) when it's ready.


(BCC: labwc and wayfire maintainer)

New wlroots is now built and tagged into 'f38-build-side-60585'.
Use 'fedpkg build --target=f38-build-side-60585' if you want to update 
your packages that require 0.16. Or wait until I merge the side tag into 
rawhide in ~1 day -- no practical difference.



***

I'm also planning to update wlroots in f37 once 0.16.1 is available.
There are a plenty of bug fixes and some important security features 
(ext-session-lock-v1) that, I believe, should not require waiting 
another 6 months for f38.


Sway will likely not be included in the initial f37 update, but may 
follow later when it gets sufficient testing.


[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0





OpenPGP_signature
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Openvdb 10.0.1 failed on ppc64 architecture

[Dan Horák]

On Thu, 1 Dec 2022 17:51:08 -0800
Luya Tshimbalanga  wrote:

> Hello team,
> 
> openvdb only failed on ppc64 architecture due to this error:
> 
> --
> 
> [ 75%] Building CXX object 
> openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o
> cd /builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb && 
> /usr/bin/g++ -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB 
> -DOPENVDB_PRIVATE -DOPENVDB_STATICLIB -DOPENVDB_USE_DELAYED_LOADING 
> -I/builddir/build/BUILD/openvdb-10.0.1/openvdb/openvdb/.. 
> -I/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb 
> -I/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb/openvdb
>  -I/builddir/build/BUILD/openvdb-10.0.1/openvdb/openvdb/. -O2 -flto=auto 
> -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8 
> -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection 
> -Wl,--as-needed -DNDEBUG -std=c++17 -MD -MT 
> openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o 
> -MF CMakeFiles/openvdb_s
 tatic.dir/instantiations/Composite.cc.o.d -o 
CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o -c 
/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb/instantiations/Composite.cc
> g++: fatal error: Killed signal terminated program cc1plus
> compilation terminated.
> gmake[2]: *** [openvdb/openvdb/CMakeFiles/openvdb_shared.dir/build.make:625: 
> openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o]
>  Error 1
> gmake[2]: *** Deleting file 
> 'openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o'
> gmake[2]: *** Waiting for unfinished jobs
> --
> 
> Could someone investigate the issue for that architecture? We may 
> possibly temporarily disable that support  until the problem gets 
> resolved. Included is the attached spec yet committed.

I will take a closer look, but it looks to me like "OOM killer in
action", thus reducing build parallelism might help.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mystery fedpkg srpm failure

[Florian Weimer]

* Aleksei Bavshin:

> On 12/1/22 23:18, Aleksei Bavshin wrote:
>> On 12/1/22 22:28, Florian Weimer wrote:
>>> I don't see what spec file aspect is causing this failure:
>>>
>>> $ fedpkg clone -a cups-bjnp
>>> Cloning into 'cups-bjnp'...
>>> remote: Enumerating objects: 278, done.
>>> remote: Counting objects: 100% (278/278), done.
>>> remote: Compressing objects: 100% (222/222), done.
>>> remote: Total 278 (delta 112), reused 96 (delta 47), pack-reused 0
>>> Receiving objects: 100% (278/278), 158.64 KiB | 752.00 KiB/s, done.
>>> Resolving deltas: 100% (112/112), done.
>>> $ cd cups-bjnp
>>> $ fedpkg srpm
>>> Not downloading unused cups-bjnp-2.0.3.tar.gz
>>>
>>> setting SOURCE_DATE_EPOCH=1669852800
>>> error: Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz: No
>>> such file or directory
>>>
>>> RPM build errors:
>>>  Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz: No
>>> such file or directory
>>> Could not execute srpm: Failed to execute command.
>>>
>>> fedpkg-simple doesn't have this problem (presumably because it downloads
>>> whatever is in the sources file, whether used or not), so the package
>>> builds fine in Koji.
>>>
>>> Any ideas?
>> Difference in opinions on specfile syntax :)
>> This is the regex rpkg uses to find the source/patch tags:
>>      r'^((source[0-9]*|patch[0-9]*)\s*:\s*(?P.*))\s*$'[1]
>
> Actually,
>
> r'^((source[0-9]*|patch[0-9]*):\s*(?P.*))\s*$',
>
> The line in my message was something I modified to test the hypothesis.
>
>> As you can see, it does not expect spaces between Source[0-9]* and
>> ':'.
>> rpm, however, allows the spaces and there's 6 packages in Fedora
>> that use this syntax quirk.
>> [1]: https://pagure.io/rpkg/blob/master/f/pyrpkg/spec.py#_18

Thanks, this certainly explains it.

Should I submitt a pull request for pyrpkg to use your first variant of
the regexp?  Or how should we deal with this?

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Openvdb 10.0.1 failed on ppc64 architecture

[Dan Horák]

On Fri, 2 Dec 2022 09:01:43 +0100
Dan Horák  wrote:

> On Thu, 1 Dec 2022 17:51:08 -0800
> Luya Tshimbalanga  wrote:
> 
> > Hello team,
> > 
> > openvdb only failed on ppc64 architecture due to this error:
> > 
> > --
> > 
> > [ 75%] Building CXX object 
> > openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o
> > cd /builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb 
> > && /usr/bin/g++ -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB 
> > -DOPENVDB_PRIVATE -DOPENVDB_STATICLIB -DOPENVDB_USE_DELAYED_LOADING 
> > -I/builddir/build/BUILD/openvdb-10.0.1/openvdb/openvdb/.. 
> > -I/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb 
> > -I/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb/openvdb
> >  -I/builddir/build/BUILD/openvdb-10.0.1/openvdb/openvdb/. -O2 -flto=auto 
> > -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
> > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8 
> > -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection 
> > -Wl,--as-needed -DNDEBUG -std=c++17 -MD -MT 
> > openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o 
> > -MF CMakeFiles/openvdb
 _s
>  tatic.dir/instantiations/Composite.cc.o.d -o 
> CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o -c 
> /builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb/instantiations/Composite.cc
> > g++: fatal error: Killed signal terminated program cc1plus
> > compilation terminated.
> > gmake[2]: *** 
> > [openvdb/openvdb/CMakeFiles/openvdb_shared.dir/build.make:625: 
> > openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o]
> >  Error 1
> > gmake[2]: *** Deleting file 
> > 'openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o'
> > gmake[2]: *** Waiting for unfinished jobs
> > --
> > 
> > Could someone investigate the issue for that architecture? We may 
> > possibly temporarily disable that support  until the problem gets 
> > resolved. Included is the attached spec yet committed.
> 
> I will take a closer look, but it looks to me like "OOM killer in
> action", thus reducing build parallelism might help.

I can confirm it's "OOM" indeed, I have reproduced it locally. So far I
can say 6GB per g++ process still isn't sufficient, trying to find the
required amount ...


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump

[Petr Pisar]

V Thu, Dec 01, 2022 at 04:46:06PM -0800, Adam Williamson napsal(a):
> On Wed, 2022-11-30 at 13:59 +0100, Jiri Kucera wrote:
> > Thanks for the reminder Petr. I will do the rebase in rawhide only then.
> 
> Thanks for taking care of these dependencies and announcing the bump.
> 
> For extra bonus points :D, if it's not too much trouble, it would be
> great if you could do this on a side tag in future - yes, even for
> Rawhide. Without a side tag and combined update, the openQA tests for
> the gpgme update fail:
> https://openqa.stg.fedoraproject.org/tests/overview?version=38&groupid=2&build=Update-FEDORA-2022-603eea89a3&distri=fedora
> if the gpgme bump and all dependent rebuilds were in the same update,
> the tests would pass (assuming nothing's actually broken).
> 
> Right now we're not gating Rawhide updates on test failures, but I do
> check them all, so I had to make sure all the rebuilds had actually
> been done, then add comments noting the tests need to be re-run after
> the next Rawhide compose, then remember to re-run them so all that ugly
> red ink goes away :D If/when we do start gating Rawhide on openQA
> failures, this update would be blocked by gating.
> 
There is already a dedicated test for checking RPM dependencies called
fedora-ci.koji-build.rpmdeplint.functional which caught the breakage
:

Dependency problems with repos:
nothing provides libqgpgme.so.7 needed by kdepim-addons-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kf5-libkleo-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kf5-mailcommon-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kf5-messagelib-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kget-libs-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kleopatra-libs-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kmail-libs-22.08.3-1.fc38.i686

Unfortunatelly, the results do not affect gating by default.

Actually a build whose CI is half red, as you can see on the link, should not
have been pushed even to Rawhide.

-- 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

New zlib-1.2.13

[Lukas Javorsky]

Hi,

I've been working on a zlib rebase for some time now.

I would like to introduce it to you via COPR repo [1] first before I push
it to Fedora rawhide.
If you could test installing your package or even test the zlib
functionality, the feedback would be much appreciated.

The plan is to push the new zlib-1.2.13 to Fedora Rawhide in the next week
(Thursday or Friday).

Feel free to provide any feedback you can until then.

[1] https://copr.fedorainfracloud.org/coprs/ljavorsk/zlib-1.2.13/

Thank you so much. Regards
Lukas

-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump

[Miro Hrončok]

On 02. 12. 22 1:46, Adam Williamson wrote:

On Wed, 2022-11-30 at 13:59 +0100, Jiri Kucera wrote:

Thanks for the reminder Petr. I will do the rebase in rawhide only then.


Thanks for taking care of these dependencies and announcing the bump.

For extra bonus points :D, if it's not too much trouble, it would be
great if you could do this on a side tag in future - yes, even for
Rawhide. Without a side tag and combined update, the openQA tests for
the gpgme update fail:
https://openqa.stg.fedoraproject.org/tests/overview?version=38&groupid=2&build=Update-FEDORA-2022-603eea89a3&distri=fedora
if the gpgme bump and all dependent rebuilds were in the same update,
the tests would pass (assuming nothing's actually broken).

Right now we're not gating Rawhide updates on test failures, but I do
check them all, so I had to make sure all the rebuilds had actually
been done, then add comments noting the tests need to be re-run after
the next Rawhide compose, then remember to re-run them so all that ugly
red ink goes away :D If/when we do start gating Rawhide on openQA
failures, this update would be blocked by gating.


Interesting. I saw 
https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b where side tag 
was used.


Later, there was https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3 
which only changed a small portion from the package.


Why would the tests fails for the second update?

--
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 02. 12. 22 v 8:00 Benson Muite napsal(a):



- rpms/ruby-ncurses

Taken



Why? It does not deserve to live, at least in its current (abandoned and 
deprecated) form.



Vít



- rpms/ucx

Taken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat Bugzilla fonts

[Vitaly Zaitsev via devel]

On 30/11/2022 11:54, Jens-Ulrik Petersen wrote:

I think good to open a bug against the Bugzilla product in bugzilla.


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

--
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mystery fedpkg srpm failure

[Sérgio Basto]

On Fri, 2022-12-02 at 10:14 +0100, Florian Weimer wrote:
> * Aleksei Bavshin:
> 
> > On 12/1/22 23:18, Aleksei Bavshin wrote:
> > > On 12/1/22 22:28, Florian Weimer wrote:
> > > > I don't see what spec file aspect is causing this failure:
> > > > 
> > > > $ fedpkg clone -a cups-bjnp
> > > > Cloning into 'cups-bjnp'...
> > > > remote: Enumerating objects: 278, done.
> > > > remote: Counting objects: 100% (278/278), done.
> > > > remote: Compressing objects: 100% (222/222), done.
> > > > remote: Total 278 (delta 112), reused 96 (delta 47), pack-
> > > > reused 0
> > > > Receiving objects: 100% (278/278), 158.64 KiB | 752.00 KiB/s,
> > > > done.
> > > > Resolving deltas: 100% (112/112), done.
> > > > $ cd cups-bjnp
> > > > $ fedpkg srpm
> > > > Not downloading unused cups-bjnp-2.0.3.tar.gz
> > > > 
> > > > setting SOURCE_DATE_EPOCH=1669852800
> > > > error: Bad file: /home/fweimer/cups-bjnp/cups-bjnp-
> > > > 2.0.3.tar.gz: No
> > > > such file or directory
> > > > 
> > > > RPM build errors:
> > > >  Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz:
> > > > No
> > > > such file or directory
> > > > Could not execute srpm: Failed to execute command.
> > > > 
> > > > fedpkg-simple doesn't have this problem (presumably because it
> > > > downloads
> > > > whatever is in the sources file, whether used or not), so the
> > > > package
> > > > builds fine in Koji.
> > > > 
> > > > Any ideas?
> > > Difference in opinions on specfile syntax :)
> > > This is the regex rpkg uses to find the source/patch tags:
> > >  r'^((source[0-9]*|patch[0-9]*)\s*:\s*(?P.*))\s*$'[1]
> > 
> > Actually,
> > 
> >     r'^((source[0-9]*|patch[0-9]*):\s*(?P.*))\s*$',
> > 
> > The line in my message was something I modified to test the
> > hypothesis.
> > 
> > > As you can see, it does not expect spaces between Source[0-9]*
> > > and
> > > ':'.
> > > rpm, however, allows the spaces and there's 6 packages in Fedora
> > > that use this syntax quirk.
> > > [1]: https://pagure.io/rpkg/blob/master/f/pyrpkg/spec.py#_18
> 
> Thanks, this certainly explains it.
> 
> Should I submitt a pull request for pyrpkg to use your first variant
> of
> the regexp?  Or how should we deal with this?
> 

yes , please 

> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Silent changes in Packaging Guidelines

[Vít Ondruch]

There was no response from any FPC member as far as I can tell, 
therefore I have opened FPC ticket with the same request:


https://pagure.io/packaging-committee/issue/1232


Vít


Dne 02. 11. 22 v 9:14 Petr Pisar napsal(a):

It used to be a good practice to announce changes in Packaging Guidelines
 here on this
list. The forkflow was that Fedora Packaging Committee accepted a change on
it's meeting and then announced it in their meeting notes posted here. This
workflow allowed packagers to notice the changes and apply them to their
packages.

However, this is not true anomore. E.g. In February a ban for wildcard %files
was augmented from dynamic libraries to all top-level files
:

 commit 2bc90a6463ae591ed134955485da0596c2fe958b
 Author: Carl George 
 Date:   Wed Feb 2 18:52:03 2022 -0600

 Adapt Python's explicit lists guidance to the main guidelines

 diff --git a/guidelines/modules/ROOT/pages/index.adoc 
b/guidelines/modules/ROOT/pages/index.adoc
 index 2bb4f9e..5ec0896 100644
 --- a/guidelines/modules/ROOT/pages/index.adoc
 +++ b/guidelines/modules/ROOT/pages/index.adoc
 @@ -2574,6 +2574,27 @@ The %defattr directive in the %files list
  SHOULD ONLY be used when setting a non-default value,
  or to reset to the default value after having set a non-default value.

 +=== Explicit lists
 +
 +Packagers *SHOULD NOT* simply glob everything under a shared directory.
 +
 +In particular, the following *SHOULD NOT* be used in `+%files+`:
 +
 +* `+%{_bindir}/*+`
 +* `+%{_datadir}/*+`
 +* `+%{_includedir}/*+`
 +* `+%{_mandir}/*+`
 +* `+%{_docdir}/*+`

To my surprise the first time when I get known to this new rule was today
in a review of my new package.

It could be that my memory failed. So I checked FPC and found these two
relevant issues:




Which do not contain any description or summary. Simply bunch of "+1"
comments. Then I searched a February archive of this list and found these
three FPC posts:

Schedule for Thursday's FPC Meeting (2022-02-03 17:00 UTC)

Schedule for Thursday's FPC Meeting (2022-02-10 17:00 UTC)

Schedule for Thursday's FPC Meeting (2022-02-17 17:00 UTC)


None of them mentions this change.


Could we please resume announcing substantial changes in the guidelines on
this mailing list?

-- 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Openvdb 10.0.1 failed on ppc64 architecture

[Dan Horák]

On Fri, 2 Dec 2022 10:45:59 +0100
Dan Horák  wrote:

> On Fri, 2 Dec 2022 09:01:43 +0100
> Dan Horák  wrote:
> 
> > On Thu, 1 Dec 2022 17:51:08 -0800
> > Luya Tshimbalanga  wrote:
> > 
> > > Hello team,
> > > 
> > > openvdb only failed on ppc64 architecture due to this error:
> > > 
> > > --
> > > 
> > > [ 75%] Building CXX object 
> > > openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o
> > > cd 
> > > /builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb 
> > > && /usr/bin/g++ -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB 
> > > -DOPENVDB_PRIVATE -DOPENVDB_STATICLIB -DOPENVDB_USE_DELAYED_LOADING 
> > > -I/builddir/build/BUILD/openvdb-10.0.1/openvdb/openvdb/.. 
> > > -I/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb 
> > > -I/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb/openvdb
> > >  -I/builddir/build/BUILD/openvdb-10.0.1/openvdb/openvdb/. -O2 -flto=auto 
> > > -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
> > > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> > > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8 
> > > -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection 
> > > -Wl,--as-needed -DNDEBUG -std=c++17 -MD -MT 
> > > openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o
> > >  -MF CMakeFiles/openv
 db
>  _s
> >  tatic.dir/instantiations/Composite.cc.o.d -o 
> > CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o -c 
> > /builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb/instantiations/Composite.cc
> > > g++: fatal error: Killed signal terminated program cc1plus
> > > compilation terminated.
> > > gmake[2]: *** 
> > > [openvdb/openvdb/CMakeFiles/openvdb_shared.dir/build.make:625: 
> > > openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o]
> > >  Error 1
> > > gmake[2]: *** Deleting file 
> > > 'openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o'
> > > gmake[2]: *** Waiting for unfinished jobs
> > > --
> > > 
> > > Could someone investigate the issue for that architecture? We may 
> > > possibly temporarily disable that support  until the problem gets 
> > > resolved. Included is the attached spec yet committed.
> > 
> > I will take a closer look, but it looks to me like "OOM killer in
> > action", thus reducing build parallelism might help.
> 
> I can confirm it's "OOM" indeed, I have reproduced it locally. So far I
> can say 6GB per g++ process still isn't sufficient, trying to find the
> required amount ...

I have concluded my tests and openvdb-10.0.1 builds just fine when
enough memory is available. I suggest to use

%cmake_build %limit_build -m 8192

instead of the current plain %cmake_build


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F38 proposal: GNU Make version 4.4 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/MAKE44

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Rebase GNU make in Fedora 38 from make version 4.3 to make version 4.4.

== Owner ==

* Name: [[User:djdelorie| DJ Delorie]]
* Email: d...@redhat.com


== Detailed Description ==
Make 4.4 was released on Oct 31, 2022.  It includes many bug fixes and
new features.  Fedora has been carrying some patches to the 4.3
release which are included in 4.4, reducing the workload for Fedora
builders.


== Benefit to Fedora ==

Stay up to date with upstream GNU make, make sure we have the latest
bug fixes et al, be compatible with stock GNU make.

== Scope ==
* Proposal owners: Update to GNU make 4.4

* Other developers: Package owners relying on makefile features
specific to older versions of GNU make may FTBFS and need to tweak
their Makefiles.  A
[https://gitlab.com/fedora/packager-tools/mass-prebuild mass prebuild]
run has identified at least two (apron due to
https://savannah.gnu.org/bugs/?57778 and pcmciautils due to
https://savannah.gnu.org/bugs/?60435)

* Release engineering: [https://pagure.io/releng/issues/11161]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: n/a

== Upgrade/compatibility impact ==

Users who have local projects using GNU make, which rely on features
only available in older versions of GNU make, may need to tweak their
Makefiles before rebuilding.  Packages which were built previous to
this upgrade will not be affected.

Specific backwards incompatibilities as called out in the NEWS file
for make 4.4:


* WARNING: Future backward-incompatibility!
  In the NEXT release of GNU Make, pattern rules will implement the same
  behavior change for multiple targets as explicit grouped targets, below: if
  any target of the rule is needed by the build, the recipe will be invoked if
  any target of the rule is missing or out of date.  During testing some
  makefiles were found to contain pattern rules that do not build all targets;
  this can cause issues so we are delaying this change for one release cycle
  to allow these makefiles to be updated.  GNU Make shows a warning if it
  detects this situation: "pattern recipe did not update peer target".

* WARNING: Backward-incompatibility!
  GNU Make now uses temporary files in more situations than previous releases.
  If your build system sets TMPDIR (or TMP or TEMP on Windows) and deletes the
  contents during the build, or uses restrictive permissions, this may cause
  problems.  You can choose an alternative temporary directory only for use by
  GNU Make by setting the new MAKE_TMPDIR environment variable before invoking
  make.  Note that this value CANNOT be set inside the makefile, since make
  needs to find its temporary directory before the makefiles are parsed.

* WARNING: Backward-incompatibility!
  Previously each target in a explicit grouped target rule was considered
  individually: if the targets needed by the build were not out of date the
  recipe was not run even if other targets in the group were out of date.  Now
  if any of the grouped targets are needed by the build, then if any of the
  grouped targets are out of date the recipe is run and all targets in the
  group are considered updated.

* WARNING: Backward-incompatibility!
  Previously if --no-print-directory was seen anywhere in the environment or
  command line it would take precedence over any --print-directory.  Now, the
  last setting of directory printing options seen will be used, so a command
  line such as "--no-print-directory -w" _will_ show directory entry/exits.

* WARNING: Backward-incompatibility!
  Previously the order in which makefiles were remade was not explicitly
  stated, but it was (roughly) the inverse of the order in which they were
  processed by make.  In this release, the order in which makefiles are
  rebuilt is the same order in which make processed them, and this is defined
  to be true in the GNU Make manual.

* WARNING: Backward-incompatibility!
  Previously only simple (one-letter) options were added to the MAKEFLAGS
  variable that was visible while parsing makefiles.  Now, all options are
  available in MAKEFLAGS.  If you want to check MAKEFLAGS for a one-letter
  option, expanding "$(firstword -$(MAKEFLAGS))" is a reliable way to return
  the set of one-letter options which can be examined via findstring, etc.

* WARNING: Backward-incompatibility!
  Previously makefile variables marked as export were not exported to commands
  started by the $(shell ...) function.  Now, all exported variables are
  exported to $(shell ...).  If this leads to recursion during expansion, then
  for backward-compatibility the value from the original environment is 

Re: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

We have no agenda for today, so I’m going to cancel the meeting. The last
meeting of the year will take place on December 16th.


On Thu, Dec 1, 2022 at 7:00 AM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2022-12-02 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>
>
>
> Source: https://calendar.fedoraproject.org//meeting/10133/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [SONAME BUMP] capnproto 0.10.2

[Fabio Valentini]

On Thu, Dec 1, 2022 at 7:57 PM Neal Gompa  wrote:
>
> Help would very much be appreciated, I'm currently underwater with other work.

I've prepared PRs with the version bumps for the different branches,
including lists of packages that need to be rebuilt:

- rawhide: https://src.fedoraproject.org/rpms/capnproto/pull-request/1
- f37: https://src.fedoraproject.org/rpms/capnproto/pull-request/2
- f36: https://src.fedoraproject.org/rpms/capnproto/pull-request/3
- epel9: https://src.fedoraproject.org/rpms/capnproto/pull-request/4
- epel8: https://src.fedoraproject.org/rpms/capnproto/pull-request/5

The version of capnproto in epel7 (v0.5 branch) no longer seems to be
supported by upstream.
If you think the changes and list of dependent packages look good, I
can get builds started.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [SONAME BUMP] capnproto 0.10.2

[Neal Gompa]

On Fri, Dec 2, 2022 at 10:07 AM Fabio Valentini  wrote:
>
> On Thu, Dec 1, 2022 at 7:57 PM Neal Gompa  wrote:
> >
> > Help would very much be appreciated, I'm currently underwater with other 
> > work.
>
> I've prepared PRs with the version bumps for the different branches,
> including lists of packages that need to be rebuilt:
>
> - rawhide: https://src.fedoraproject.org/rpms/capnproto/pull-request/1
> - f37: https://src.fedoraproject.org/rpms/capnproto/pull-request/2
> - f36: https://src.fedoraproject.org/rpms/capnproto/pull-request/3
> - epel9: https://src.fedoraproject.org/rpms/capnproto/pull-request/4
> - epel8: https://src.fedoraproject.org/rpms/capnproto/pull-request/5
>
> The version of capnproto in epel7 (v0.5 branch) no longer seems to be
> supported by upstream.
> If you think the changes and list of dependent packages look good, I
> can get builds started.

These all look great, and I've given thumbs for all them. Go for it!


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Fedora Sway Spin (Self-Contained Change proposal)

[Major Hayden]

On 12/1/22 11:35, Ben Cotton wrote:
> == Detailed Description ==
> Fedora Window Manager spins greatly benefit users who enjoy a minimal
> desktop. Sway is beginning to become well polished and is continuing
> to gain traction from the community. Fedora particularly has a
> first-class Wayland experience making an even more compelling use case
> for having a Wayland window manager spin.

Great idea! I've been on Sway for a few Fedora releases and it's been a
pleasure to use. I also like keeping a fairly minimal system and Sway
makes that a little easier.

> For those reasons, we propose to create a Sway spin and an ostree one,
> called `Sericea`.

What made you choose the name? (Just curious.)

I had to go look it up[0].

> The goal of both spins would be to create a turnkey environment to
> enjoy Fedora and Sway functionally and beautifully.
> To achieve this, we plan to put in those spins the minimum amount of
> packages to accomplish the stated goal. [[User:alebastr| Aleksei
> Bavshin]] has begun an
> [https://src.fedoraproject.org/rpms/sway/pull-request/12 RFC] for the
> `sway` source package that would extend it by creating three
> sub-packages with Fedora's default Sway configuration.

Good idea on the splitting. I believe this was done recently for i3, too.

> == Feedback ==
> Feedback has been low at the moment.
> We have seen wildly different feedback, from people saying they liked
> the idea and would use it to others who do not see the value of it and
> will probably not use it.
> Some commenters highlighted that this isn't worthwhile for them as
> they would prefer to have Gnome installed alongside Sway. There have
> also been comments that some users like having a minimal package set
> that only includes Sway and don't want a two-step process to get to
> their environment, which would be the situation if they install a spin
> that is not Sway and then have to install Sway on top.

I've installed Sway several times through the two-step process and
although it's not too difficult, it's not easy for new users. This means
each user must determine which Sway packages and related extras (perhaps
mako, wofi, etc) that they want to add. There's a great opportunity here
for people who know a lot about Sway to create an awesome installation
experience as well as a good Sway setup after the reboot.

The two-step process leaves me to make a lot of those decisions and look
up which extra applications I need to add.

> == Benefit to Fedora ==
> 
> Like the introduction of the i3 Spin, this change benefits end-users
> who run Fedora on a desktop or laptop, particularly low-end
> consumer-grade hardware.
> 
> A Sway Spin would provide a better initial installation experience for
> Fedora users installing Sway for the first time. Currently, end-users
> who wish to use Sway on Fedora must install another Edition or Spin of
> Fedora, then install the Sway window manager (and related packages)
> separately. Also, at the moment, the process is not documented in
> Fedora documentation, forcing the user to use an external guide or
> tutorial.
> 
> Additionally, this "two-step" (first install Fedora, then install Sway
> on top of it) method adds unnecessary packages to the user's system,
> particularly if the end-user does not wish to use another desktop
> environment. One of Fedora's foundations is being "First".
> We believe that, in this situation, being committed to being "First"
> means pushing the boundaries of Sway and Wayland by shipping the first
> Fedora Spin that is based on a Wayland-only Window Manager.

Well said. Thanks for proposing this change. 👏🏻

[0] https://en.wikipedia.org/wiki/Cornus_sericea

-- 
Major Hayden
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mystery fedpkg srpm failure

[Florian Weimer]

* Sérgio Basto:

>> > > As you can see, it does not expect spaces between Source[0-9]*
>> > > and
>> > > ':'.
>> > > rpm, however, allows the spaces and there's 6 packages in Fedora
>> > > that use this syntax quirk.
>> > > [1]: https://pagure.io/rpkg/blob/master/f/pyrpkg/spec.py#_18
>> 
>> Thanks, this certainly explains it.
>> 
>> Should I submitt a pull request for pyrpkg to use your first variant
>> of
>> the regexp?  Or how should we deal with this?
>> 
>
> yes , please 

Done: 

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: OpenCOLLADA dead upstream

[Richard Shaw]

On Fri, Dec 2, 2022 at 12:51 AM Luya Tshimbalanga 
wrote:

> On 2022-11-30 17:55, Richard Shaw wrote:
>
> So it looks like the last commit was in 2018:
>
> https://github.com/KhronosGroup/OpenCOLLADA
>
> Before we go ripping it out of Fedora, is anyone aware of another active
> upstream we can port to?
>
> A fork version is available on
> https://github.com/RemiArnaud/OpenCOLLADA/releases
>

Thanks! That's very helpful.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Anaconda-devel] Anaconda Web UI

[Jiri Konecny]

Hi,

I'm sorry you feel it this way. Just want to point you to mount-point 
assignment feature which is in Anaconda for some time already (only text 
UI) where you are able to do your partitioning as you want and just 
assign that a mount points in Anaconda.


I hope that helps.

Best Regards,
Jirka

Dne 30. 11. 22 v 6:37 gius db napsal(a):

Hi.

Without controversy, developers and maintainers have every right to do 
things their own way and refuse requests.


I my case, the installer's first problem isn't the interface, it's the 
lack of functionality, functions that have been blocked, the inability 
to bypass limits.


In my case, it lacks the ability to upgrade/install over an existing 
installation, install over already existing empty partitions, use 
gparted, etc. .


My feeling when using the installer is that I am a prisoner of a 
closed system without having enough advantages.


gdb

___
Anaconda-devel mailing list -- anaconda-de...@lists.fedoraproject.org
To unsubscribe send an email to anaconda-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/anaconda-de...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora Review Service

[Jakub Kadlcik]

Hello folks,

for a couple of years now, I've been interested in the Fedora package
review process. Our queue is in hundreds of waiting packages for as
long as I can remember. I believe the situation can be improved.

Since summer, I did ~40 package reviews to get a better grasp of the
situation and realized what I want to do.

I started working on a service [2] that listens to fedora-messaging
and for every new RHBZ review ticket or a new comment with updated
packages, it submits a build in Copr. Thanks to this [1] feature, Copr
automatically runs the fedora-review tool and generates the
review.txt file. Once the build is finished, my service gets the
message and generates a helpful comment (so far only to STDOUT).

**Unless there is general disapproval, I am planning to let it post
the comments to Bugzilla.**

So far the benefit is limited but, it still can immediately tell the
contributor that their package is broken and fails to build, and also
saves a reviewer the time of running the fedora-review tool
manually. However, I also implemented support for the fedora-review
tool to generate a JSON output next to the standard review.txt. The PR
is still pending [2], please review it if you can. Once this is
released, I can parse its contents and generate much helpful comments
for the contributors.

The end goal is to let contributors go back and forth against the CI
to fix the most obvious mistakes and then let the reviewers take
only the final look.

Hopefully, it will be a better experience for everyone.


[1] http://frostyx.cz/posts/running-fedora-review-after-copr-build
[2] https://github.com/FrostyX/fedora-review-service
[3] https://pagure.io/FedoraReview/pull-request/463

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Review Service

[Iñaki Ucar]

On Fri, 2 Dec 2022 at 18:21, Jakub Kadlcik  wrote:
>
> Hello folks,
>
> for a couple of years now, I've been interested in the Fedora package
> review process. Our queue is in hundreds of waiting packages for as
> long as I can remember. I believe the situation can be improved.
>
> Since summer, I did ~40 package reviews to get a better grasp of the
> situation and realized what I want to do.
>
> I started working on a service [2] that listens to fedora-messaging
> and for every new RHBZ review ticket or a new comment with updated
> packages, it submits a build in Copr. Thanks to this [1] feature, Copr
> automatically runs the fedora-review tool and generates the
> review.txt file. Once the build is finished, my service gets the
> message and generates a helpful comment (so far only to STDOUT).
>
> **Unless there is general disapproval, I am planning to let it post
> the comments to Bugzilla.**

Yes, please! This seems like a **very** helpful service to me. Thanks
for this! :)

Iñaki

> So far the benefit is limited but, it still can immediately tell the
> contributor that their package is broken and fails to build, and also
> saves a reviewer the time of running the fedora-review tool
> manually. However, I also implemented support for the fedora-review
> tool to generate a JSON output next to the standard review.txt. The PR
> is still pending [2], please review it if you can. Once this is
> released, I can parse its contents and generate much helpful comments
> for the contributors.
>
> The end goal is to let contributors go back and forth against the CI
> to fix the most obvious mistakes and then let the reviewers take
> only the final look.
>
> Hopefully, it will be a better experience for everyone.
>
>
> [1] http://frostyx.cz/posts/running-fedora-review-after-copr-build
> [2] https://github.com/FrostyX/fedora-review-service
> [3] https://pagure.io/FedoraReview/pull-request/463
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Review Service

[Adam Williamson]

On Fri, 2022-12-02 at 18:20 +0100, Jakub Kadlcik wrote:
> Hello folks,
> 
> for a couple of years now, I've been interested in the Fedora package
> review process. Our queue is in hundreds of waiting packages for as
> long as I can remember. I believe the situation can be improved.
> 
> Since summer, I did ~40 package reviews to get a better grasp of the
> situation and realized what I want to do.
> 
> I started working on a service [2] that listens to fedora-messaging
> and for every new RHBZ review ticket or a new comment with updated
> packages, it submits a build in Copr. Thanks to this [1] feature, Copr
> automatically runs the fedora-review tool and generates the
> review.txt file. Once the build is finished, my service gets the
> message and generates a helpful comment (so far only to STDOUT).
> 
> **Unless there is general disapproval, I am planning to let it post
> the comments to Bugzilla.**

This sounds great! Thanks for working on it.

Where does this service currently run? If it's going to be used "in
anger", perhaps it would be good to put it under fedora-infra control?
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

[Michael Dawson]

Great to see all the interest so far. Will continue to point people to this 
thread to collect those who are interested in being involved and will look to 
get the SIG rolling early in the new year.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [SONAME BUMP] capnproto 0.10.2

[Fabio Valentini]

On Fri, Dec 2, 2022 at 4:13 PM Neal Gompa  wrote:
>
> On Fri, Dec 2, 2022 at 10:07 AM Fabio Valentini  wrote:
> >
> > On Thu, Dec 1, 2022 at 7:57 PM Neal Gompa  wrote:
> > >
> > > Help would very much be appreciated, I'm currently underwater with other 
> > > work.
> >
> > I've prepared PRs with the version bumps for the different branches,
> > including lists of packages that need to be rebuilt:
> >
> > - rawhide: https://src.fedoraproject.org/rpms/capnproto/pull-request/1
> > - f37: https://src.fedoraproject.org/rpms/capnproto/pull-request/2
> > - f36: https://src.fedoraproject.org/rpms/capnproto/pull-request/3
> > - epel9: https://src.fedoraproject.org/rpms/capnproto/pull-request/4
> > - epel8: https://src.fedoraproject.org/rpms/capnproto/pull-request/5
> >
> > The version of capnproto in epel7 (v0.5 branch) no longer seems to be
> > supported by upstream.
> > If you think the changes and list of dependent packages look good, I
> > can get builds started.
>
> These all look great, and I've given thumbs for all them. Go for it!

All builds were successful, and updates have been filed:

Rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ef11bad952
F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-18023b665f
F36: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5d37367673
EPEL9: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4b56675171
EPEL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-8108a34445

Let me know if there are any problems.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue