Re: clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'

[Dan Horák]

On Mon, 15 Apr 2024 10:55:34 +0100
"Richard W.M. Jones"  wrote:

> 
> Anyone got any idea about this build failure?
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=116395331
> 
> [+] All set and ready to build.
> clang: warning: -Wl,-z,relro: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -Wl,--as-needed: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -Wl,-z,pack-relative-relocs: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -Wl,-z,now: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -Wl,--build-id=sha1: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -ldl: 'linker' input unused [-Wunused-command-line-argument]
> clang: warning: -lrt: 'linker' input unused [-Wunused-command-line-argument]
> clang: warning: -lm: 'linker' input unused [-Wunused-command-line-argument]
> clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for 
> target 'x86_64-redhat-linux-gnu'
> 
> AFAICT -mtls-dialect=gnu2 is not added by anything in the spec file or
> in AFL++ sources, so it must be coming from RPM macros?

it comes from "x86-64 -mtls-dialect=gnu2 change landed in rawhide", see
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M2SCED77ZDJQ7BHWU5LCRGMUSHV6L3CY/


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: Self Introduction: Aditi Mishra

[Dan Horák]

Hello Aditi,

On Thu, 11 Apr 2024 22:31:41 +0530
Aditi Mishra  wrote:

> Hello everyone,
> 
> I'm very new to open-source world however I'm willing and passionate 
> candiate to work with you all. I had worked in the field of linux 
> scheduler area as an intern. Willing to learn fedora packing and wants 
> to contribute my work in future journey of fedora.
> 
> Looking forward for your help.

welcome in the community :-) Feel free to reach me in case of any
Fedora related questions.


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

[heads up] update to astyle 3.4.13 without soname bump in rawhide

[Dan Horák]

Hi, 

I have updated astyle to the latest 3.4.13 version that changes ABI,
but keeps soname. The 2 dependent packages were successfully rebuilt in
a side-tag.

[dan@talos ~]$ sudo dnf --repoid=rawhide-source --arch=src repoquery 
--whatrequires astyle-devel
codeblocks-0:20.03-21.20240128svn13434.fc40.src
kdevelop-9:24.02.1-1.fc41.src


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: [Test-Announce] Fedora 40 Candidate Beta-1.9 Available Now!

[Dan Horák]

On Wed, 20 Mar 2024 08:47:14 -0400
Neal Gompa  wrote:

> On Wed, Mar 20, 2024 at 8:45 AM Dan Horák  wrote:
> >
> > On Tue, 19 Mar 2024 12:41:48 + (UTC)
> > rawh...@fedoraproject.org wrote:
> >
> > > According to [the schedule][1], Fedora 40 Candidate Beta-1.9 is now
> > > available for testing. Please help us complete all the validation
> > > testing! For more information on release validation testing, see:
> > >  https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> > >
> > > Test coverage information for the current release can be seen at:
> > >  https://openqa.fedoraproject.org/testcase_stats/40
> > >
> > > You can see all results, find testing instructions and image download
> > > locations, and enter results on the Summary page:
> > >
> > >  https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Summary
> > >
> > > The individual test result pages are:
> > >
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Installation
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Base
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Server
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Cloud
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Desktop
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Security_Lab
> > >
> > > All Beta priority test cases for each of these [test pages][2] must
> > > pass in order to meet the [Beta Release Criteria][3].
> > >
> > > Help is available on [the Fedora Quality chat channel][4], [the Fedora
> > > Quality tag on Discourse][5], or on [the test list][6].
> > >
> > > Current Blocker and Freeze Exception bugs:
> > >  https://qa.fedoraproject.org/blockerbugs/current
> > >
> > > [1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html
> > > [2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> > > [3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
> > > [4]: 
> > > https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
> > > [5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team
> > > [6]: 
> > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
> >
> > the Cloud and Container image filenames miss the "Beta" string in the
> > name, not sure, but someone might have mentioned it already ...
> >
> > for example
> > Fedora-Cloud-Base-Generic.ppc64le-40-1.9.qcow2
> > should be
> > Fedora-Cloud-Base-Generic.ppc64le-40-Beta_1.9.qcow2
> > I believe. The checksum filename is correct.
> >
> 
> This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2270197
> 
> We have an upstream fix to kiwi for this, but some code will need to
> be written for the koji plugin and pungi to resolve it.

thanks for the pointer. I have noticed it, because I am using
https://github.com/sharkcz/tools/blob/master/check-compose to check
what artifacts are actually available (limited to my "multi-arch" view).


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: [Test-Announce] Fedora 40 Candidate Beta-1.9 Available Now!

[Dan Horák]

On Tue, 19 Mar 2024 12:41:48 + (UTC)
rawh...@fedoraproject.org wrote:

> According to [the schedule][1], Fedora 40 Candidate Beta-1.9 is now
> available for testing. Please help us complete all the validation
> testing! For more information on release validation testing, see:
>  https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> 
> Test coverage information for the current release can be seen at:
>  https://openqa.fedoraproject.org/testcase_stats/40
> 
> You can see all results, find testing instructions and image download
> locations, and enter results on the Summary page:
> 
>  https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Summary
> 
> The individual test result pages are:
> 
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Installation
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Base
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Server
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Cloud
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Desktop
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Security_Lab
> 
> All Beta priority test cases for each of these [test pages][2] must
> pass in order to meet the [Beta Release Criteria][3].
> 
> Help is available on [the Fedora Quality chat channel][4], [the Fedora
> Quality tag on Discourse][5], or on [the test list][6].
> 
> Current Blocker and Freeze Exception bugs:
>  https://qa.fedoraproject.org/blockerbugs/current
> 
> [1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html
> [2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> [3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
> [4]: 
> https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
> [5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team
> [6]: 
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/

the Cloud and Container image filenames miss the "Beta" string in the
name, not sure, but someone might have mentioned it already ...

for example
Fedora-Cloud-Base-Generic.ppc64le-40-1.9.qcow2
should be
Fedora-Cloud-Base-Generic.ppc64le-40-Beta_1.9.qcow2
I believe. The checksum filename is correct.


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: Follow up for bash-completion pkgconfig file packaging change

[Dan Horák]

On Mon, 18 Mar 2024 17:07:08 +0100
Fabio Valentini  wrote:

> On Mon, Mar 18, 2024 at 4:33 PM Mamoru TASAKA  
> wrote:
> >
> > Hello, all:
> >
> > After investigating the recent Fedora-Security-Live livespin compose failure
> > on F-41, it is found that this is caused because:
> >
> > - Recently on F-41, bash-completion packaging changed so that pkgconfig file
> >is moved into -devel subpackage: (bash-completion-2.11-15.fc41)
> >
> > https://src.fedoraproject.org/rpms/bash-completion/c/d1f5dc48c0440cc68efdd519b78fccca416cad94?branch=rawhide
> >
> > - A package (lynis) installing bash-completion file into the directory
> >$(pkg-config --variable=completionsdir bash-completion), had 
> > "BuildRequires: bash-completion",
> >but did not have "BuildRequires: pkgconfig(bash-completion)".
> >
> > - So after the above bash-completion side packaging change, the above 
> > command line was
> >expanded to the empty string, so the completion file was installed into 
> > the wrong directory,
> >which caused conflict with filesystem rpm.
> >
> >
> > So on F-41(rawhide), the packages
> >
> > * trying to install bash-completion file using $(pkg-config 
> > --variable=completionsdir bash-completion)
> > * which have "BuildRequires: bash-completion", but do NOT have 
> > "BuildRequires: pkgconfig(bash-completion)"
> >
> > may be installing completion file into wrong directories after rebuild.
> > (At least, I tried rebuilding cowsay and actually it installs completion 
> > file into the wrong
> >   directory).
> 
> I wonder why these packages rely in pkg-config and don't just install
> to `%{bash_completions_dir}`?

because it hasn't always exist? Or it's mentioned in some guidelines?


Dan

> This macro is defined in the default buildroot, regardless of
> BuildRequires, and always expands to the correct location for
> installing bash completions.
> 
> 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
--
___
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: Follow up for bash-completion pkgconfig file packaging change

[Dan Horák]

On Mon, 18 Mar 2024 15:46:46 +
Gwyn Ciesla via devel  wrote:

> Thanks, lynis is fixed, cowsay will be momentarily.

and mt-st is fixed as well


Dan

> 
> 
> 
> -- 
> Gwyn Ciesla
> she/her/hers
>  
> in your fear, seek only peace 
> in your fear, seek only love
> -d. bowie
> 
> 
> Sent with Proton Mail secure email.
> 
> On Monday, March 18th, 2024 at 10:33 AM, Mamoru TASAKA 
>  wrote:
> 
> > Hello, all:
> > 
> 
> > After investigating the recent Fedora-Security-Live livespin compose failure
> > on F-41, it is found that this is caused because:
> > 
> 
> > - Recently on F-41, bash-completion packaging changed so that pkgconfig file
> > is moved into -devel subpackage: (bash-completion-2.11-15.fc41)
> > https://src.fedoraproject.org/rpms/bash-completion/c/d1f5dc48c0440cc68efdd519b78fccca416cad94?branch=rawhide
> > 
> 
> > - A package (lynis) installing bash-completion file into the directory
> > $(pkg-config --variable=completionsdir bash-completion), had 
> > "BuildRequires: bash-completion",
> > but did not have "BuildRequires: pkgconfig(bash-completion)".
> > 
> 
> > - So after the above bash-completion side packaging change, the above 
> > command line was
> > expanded to the empty string, so the completion file was installed into the 
> > wrong directory,
> > which caused conflict with filesystem rpm.
> > 
> 
> > 
> 
> > So on F-41(rawhide), the packages
> > 
> 
> > * trying to install bash-completion file using $(pkg-config 
> > --variable=completionsdir bash-completion)
> > * which have "BuildRequires: bash-completion", but do NOT have 
> > "BuildRequires: pkgconfig(bash-completion)"
> > 
> 
> > may be installing completion file into wrong directories after rebuild.
> > (At least, I tried rebuilding cowsay and actually it installs completion 
> > file into the wrong
> > directory).
> > 
> 
> > The possible packages which may need fixing are:
> > 
> 
> > 1 cowsay/rawhide/cowsay.spec %global compdir %(pkg-config 
> > --variable=completionsdir bash-completion)
> > 2 creds/rawhide/creds.spec %global bashcompdir %(pkg-config 
> > --variable=completionsdir bash-completion)
> > 3 datamash/rawhide/datamash.spec pkg-config --variable=completionsdir 
> > bash-completion ||
> > 4 dracut/rawhide/dracut.spec --bashcompletiondir=$(pkg-config 
> > --variable=completionsdir bash-completion) \
> > 5 eg/rawhide/eg.spec bashcompdir=$(pkg-config --variable=completionsdir 
> > bash-completion || :)
> > 6 fedpkg/rawhide/fedpkg.spec %define compdir %(pkg-config 
> > --variable=completionsdir bash-completion)
> > 7 git-annex/rawhide/git-annex.spec 
> > bash_completion_dir=%{buildroot}$(pkg-config --variable=completionsdir 
> > bash-completion)
> > 8 gromacs/rawhide/gromacs.spec %define compdir %(pkg-config 
> > --variable=completionsdir bash-completion)
> > 9 kim-api/rawhide/kim-api.spec %global b_compdir %(pkg-config 
> > --variable=completionsdir bash-completion)
> > 10 mpc/rawhide/mpc.spec %global compdir %(pkg-config 
> > --variable=completionsdir bash-completion)
> > 11 mt-st/rawhide/mt-st.spec COMPLETIONDIR=%{buildroot}$(pkg-config 
> > --variable=completionsdir bash-completion)
> > 12 pybugz/rawhide/pybugz.spec %global bash_cmpl_dir %(pkg-config 
> > --variable=completionsdir bash-completion)
> > 13 python-django/rawhide/python-django.spec bashcompdir=$(pkg-config 
> > --variable=completionsdir bash-completion)
> > 14 python-vitrageclient/rawhide/python-vitrageclient.spec 
> > bashcompdir=$(pkg-config --variable=completionsdir bash-completion)
> > 15 tig/rawhide/tig.spec %global bash_completion_dir %(pkg-config 
> > --variable=completionsdir bash-completion || echo /etc/bash_completion.d)/
> > 
> 
> > Regards,
> > Mamoru
> > --
> > ___
> > 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: Why can't I add karlowich as co-maintainer of this package?

[Dan Horák]

On Mon, 18 Mar 2024 09:57:58 +
"Richard W.M. Jones"  wrote:

> 
> https://src.fedoraproject.org/rpms/xnvme/adduser
> 
> I try to add karlowich (https://accounts.fedoraproject.org/user/karlowich/)
> but his name doesn't appear in the username field even though he's
> in the packager group.  Why?

they might need to re-login to src.fp.o after being added to the
packager group to refresh the permissions


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: A note about riscv64 changes

[Dan Horák]

On Wed, 14 Feb 2024 12:29:00 +
Peter Robinson  wrote:

> On Wed, 14 Feb 2024 at 12:07, David Abdurachmanov
>  wrote:
> >
> > On Wed, Feb 14, 2024 at 12:49 PM Dan Horák  wrote:
> > >
> > > On Wed, 14 Feb 2024 10:42:52 +
> > > "Richard W.M. Jones"  wrote:
> > >
> > > > On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > > > > Hi Richard,
> > > > >
> > > > > > A quick note that you may be seeing pull requests for riscv64 
> > > > > > changes
> > > > > > against your packages, like these examples:
> > > > > >
> > > > > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > > > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > > > > >
> > > > > > For many years we have been building Fedora for the RISC-V
> > > > > > architecture on a separate build system at
> > > > > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > > > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > > > > (Most of this work was done by David Abdurachmanov, not me.)
> > > > >
> > > > > I'm very happy to see these start to land, let me know if you need any
> > > > > assistance.
> > > > >
> > > > > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > > > > although only (hopefully!) where it doesn't break ordinary builds 
> > > > > > and
> > > > > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > > > > free to make comments if you disagree with changes.
> > > > > >
> > > > > > Some time, with any luck soon, we will be creating a new Koji 
> > > > > > instance
> > > > > > with FAS authentication which will allow anyone to optionally build
> > > > > > their packages on RISC-V builders.  And then later in the year we 
> > > > > > may
> > > > > > be in a position with the availability of new hardware to discuss
> > > > > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > > > > current hardware is far too slow to force it on Fedora developers.)
> > > > >
> > > > > Will this instance run with koji-shadow to properly mirror the builds
> > > > > with all the appropriate NVR dependencies to properly mirror Fedora
> > > > > primary builds?
> > > >
> > > > TBD.
> > > >
> > > > Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> > > > something together with scripts, or get koji-shadow working.
> > >
> > > on the other hand, it's still tags, targets, buildroots in koji ...
> > >
> > > I should be able dig out some koji-shadow know-how out of my memory if
> > > needed. Those were wonderful years :-)
> >
> > Many years ago I tried using koji-shadow, but I didn't like what it
> > was doing. Cooking something custom seemed easier at that point. These
> 
> Yes, it was never a particularly nice process, but the advantage it
> has was it made sure that a package build used the exact same packages
> as on the mainline build so you could end up with identical builds and
> that was very useful for bugs and build process problems.

and with that technique it solves the soname bumps and the use of side
tags very effectively, I would consider this the main benefit of
koji-shadow


Dan
 
> > days we also have side tags, and thus some bootstrap operations happen
> > there. Sadly those get removed relatively soonish after the tag gets
> > merged. Sometimes before I get a chance to grab it. Otherwise I have a
> > good picture of Fedora package land over so many years.
> >
> > Our "dist-git overlay" is relatively small these days. Should be <300
> > packages, and majority of it was used to bump NVR for rebuilds.
> >
> > Cheers,
> > david
> >
> > >
> > > 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.o

Re: A note about riscv64 changes

[Dan Horák]

On Wed, 14 Feb 2024 10:42:52 +
"Richard W.M. Jones"  wrote:

> On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > Hi Richard,
> > 
> > > A quick note that you may be seeing pull requests for riscv64 changes
> > > against your packages, like these examples:
> > >
> > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > >
> > > For many years we have been building Fedora for the RISC-V
> > > architecture on a separate build system at
> > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > (Most of this work was done by David Abdurachmanov, not me.)
> > 
> > I'm very happy to see these start to land, let me know if you need any
> > assistance.
> > 
> > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > although only (hopefully!) where it doesn't break ordinary builds and
> > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > free to make comments if you disagree with changes.
> > >
> > > Some time, with any luck soon, we will be creating a new Koji instance
> > > with FAS authentication which will allow anyone to optionally build
> > > their packages on RISC-V builders.  And then later in the year we may
> > > be in a position with the availability of new hardware to discuss
> > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > current hardware is far too slow to force it on Fedora developers.)
> > 
> > Will this instance run with koji-shadow to properly mirror the builds
> > with all the appropriate NVR dependencies to properly mirror Fedora
> > primary builds?
> 
> TBD.
> 
> Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> something together with scripts, or get koji-shadow working.

on the other hand, it's still tags, targets, buildroots in koji ...

I should be able dig out some koji-shadow know-how out of my memory if
needed. Those were wonderful years :-)


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: Koji: virtual memory exhausted: Cannot allocate memory

[Dan Horák]

On Mon, 12 Feb 2024 07:02:28 -0600
"W. Michael Petullo"  wrote:

> Building the current version of my opengrm-ngram package on Koji fails
> with the error "virtual memory exhausted: Cannot allocate memory"
> as indicated below. This happens only for i686; all of the other
> architectures build. Is this the fault of my package, or did something
> change at https://koji.fedoraproject.org?

the package (and its build enviroment) has grown. It fails because
32-bit system means max 4GB of address space for a process and ld runs
as a single process, so it's not uncommon to use all memory for large
C++ projects.

You can try disabling or reducing the size of debuginfo (from -g to -g1
or even -g0) to reduce the size of the *.o files. This usually helps.
Another option is to drop the i686 build per
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval


Dan

> 
> [...]
> libtool: link: g++ -Wl,--as-needed -std=c++17 -fno-exceptions  -fPIC -DPIC 
> -shared -nostdlib /usr/lib/gcc/i686-redhat-linux/14/../../../crti.o 
> /usr/lib/gcc/i686-redhat-linux/14/crtbeginS.o  .libs/ngram-absolute.o 
> .libs/ngram-context.o .libs/ngram-count.o .libs/ngram-count-prune.o 
> .libs/ngram-input.o .libs/ngram-kneser-ney.o .libs/ngram-list-prune.o 
> .libs/ngram-make.o .libs/ngram-marginalize.o .libs/ngram-output.o 
> .libs/ngram-shrink.o .libs/util.o   -ldl -L/usr/lib/fst -lfst -lgsl 
> -lflexiblas -L/usr/lib/gcc/i686-redhat-linux/14 
> -L/usr/lib/gcc/i686-redhat-linux/14/../../.. -lstdc++ -lm -lc -lgcc_s 
> /usr/lib/gcc/i686-redhat-linux/14/crtendS.o 
> /usr/lib/gcc/i686-redhat-linux/14/../../../crtn.o -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -flto=auto -g 
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 
> -march=i686 -mtune
 =generic -msse2 -mfpmath=sse -mstackrealign -Wl,-z -Wl,relro -Wl,--as-needed 
-Wl,-z -Wl,pack-relative-relocs -Wl,-z -Wl,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 
-specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,-rpath=/usr/lib/fst   
-Wl,-soname -Wl,libngram.so.1315 -o .libs/libngram.so.1315.0.0
> libtool: link: (cd ".libs" && rm -f "libngram.so.1315" && ln -s 
> "libngram.so.1315.0.0" "libngram.so.1315")
> libtool: link: (cd ".libs" && rm -f "libngram.so" && ln -s 
> "libngram.so.1315.0.0" "libngram.so")
> libtool: link: ( cd ".libs" && rm -f "libngram.la" && ln -s "../libngram.la" 
> "libngram.la" )
> virtual memory exhausted: Cannot allocate memory
> [...]
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=113388137
> 
> -- 
> Mike
> 
> :wq
> --
> ___
> 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

[heads up] update to sg3_utils-1.48 with soname bump in rawhide

[Dan Horák]

Hi, 

I am in process of updating sg3_utils to the latest 1.48 version that
brings a soname bump. The dependent packages will be rebuilt in a
sidetag. All the deps build fine in my testing.

sudo dnf --repoid=rawhide repoquery --whatrequires sg3_utils-libs
ddpt-0:0.97-8.fc40
ledmon-0:0.97-4.fc40
libgpod-0:0.8.3-50.fc40
lsvpd-0:1.7.15-3.fc40
udisks-0:1.0.5-25.fc40


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: Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available

[Dan Horák]

On Tue, 6 Feb 2024 13:11:55 +0100
Sandro Mani  wrote:

> 
> On 06.02.24 8:50 AM, Marc-André Lureau wrote:
> > Hi
> >
> > On Mon, Feb 5, 2024 at 8:52 PM Daniel P. Berrangé  
> > wrote:
> >> On Mon, Feb 05, 2024 at 05:34:06PM +0100, Dan Horák wrote:
> >>> Hi,
> >>>
> >>> could someone in the mingw team look at mingw-libgsf / libgsf (please
> >>> see the bug forwarded below)? If I see right, then the standalone
> >>> mingw-libgsf package should be retired as there are mingw builds from
> >>> the regular libgsf package, which seems to be regularly updated.
> >> Copying Marc-André who added the mingw sub-RPMs to the native
> >> package.
> >>
> >> The mingw-libgsf should have been retired on rawhide, as soon
> >> as the libgsf native had a successful build with mingw packages.
> >>
> >> At this point I guess it'll need retiring on both rawhide
> >> and f39
> > Correct, I missed that. Geg, Sandro, can you retire the mingw-libgsf 
> > package?
> >
> I've retired the package, but not sure if it worked 100% as I'm not 
> listed as package admin.

I suspect it hasn't finished the retiring, mingw-libgfs is still active
in koji and in pagure ... Likely it needs either Greg (who seems to be
inactive) or a releng ticket.


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

Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available

[Dan Horák]

Hi,

could someone in the mingw team look at mingw-libgsf / libgsf (please
see the bug forwarded below)? If I see right, then the standalone
mingw-libgsf package should be retired as there are mingw builds from
the regular libgsf package, which seems to be regularly updated.


Thanks,

Dan



Begin forwarded message:

Date: Mon, 05 Feb 2024 00:09:44 +
From: bugzi...@redhat.com
Subject: [Bug 2066129] mingw-libgsf-1_14_52 is available


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

Upstream Release Monitoring
 changed:

   What|Removed |Added

Summary|mingw-libgsf-1_14_51 is |mingw-libgsf-1_14_52 is
   |available   |available



--- Comment #8 from Upstream Release Monitoring
 --- Releases retrieved:
1_14_52 Upstream release that is considered latest: 1_14_52
Current version/release in rawhide: 1.14.48-7.fc40
URL: http://www.gnome.org/projects/libgsf/

Please consult the package updates policy before you issue an update to
a stable branch:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found
at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be
packaging changes that need to be made. Specifically, please remember
that it is your responsibility to review the new version to ensure that
the licensing is still correct and that no non-free or legally
problematic items have been added upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/1980/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/mingw-libgsf


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2066129

Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202066129%23c8
--
___
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: Failure on fedora default backgrounds

[Dan Horák]

On Fri, 2 Feb 2024 23:55:43 -0800
l...@fedoraproject.org wrote:

> 
> 
> On 2024-02-01 11:26 p.m., Neal Gompa  wrote:
> > On Fri, Feb 2, 2024 at 2:04 AM Mamoru TASAKA  
> > wrote:
> > >
> > > Luya Tshimbalanga wrote on 2024/02/02 10:25:
> > >> Hello team,
> > >>
> > >> It appears a change within %{_kde4_datadir} macro caused failures on 
> > >> Rawhide affecting default Fedora backgrounds starting from 21.
> > >> Could someone from KDE SIG address that issue? Thanks.
> > >>
> > >>
> > >> Here is an extract of failure[1]  on for f35-backgrounds built on 
> > >> Rawhide:
> > >>
> > >> 
> > >>
> > >> RPM build errors:
> > >> error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > >>   File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > >> Child return code was: 1
> > >> '''
> > >>
> > >> Reference:
> > >> [1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075
> > >>
> > >
> > > I am not KDE sig member, but the above failure is most likely due to
> > > the following change:
> > >
> > > https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32
> > >
> > > /usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir} macro 
> > > definition)
> > > was moved from kde-filesystem.rpm to kde4-filesystem.rpm .
> > >
> > 
> > Yes, just add "BuildRequires: kde4-filesystem".
> > 
> 
> Thank you all for the solution. I notice I lack access to commit changes on  
> f21-backgrounds so proven packagers are welcome to do so. Thanks

update to f21-backgrounds pushed into git, no build started

Is the Requires: kde-filesystem in the "kde" subpackage still correct?


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: HELP! What's up with OpenVDB?

[Dan Horák]

On Sun, 28 Jan 2024 15:57:15 -0600
Richard Shaw  wrote:

> On Sun, Jan 28, 2024 at 9:55 AM Ben Beasley  wrote:
> 
> > Blender already excludes i686:
> >
> >
> > https://src.fedoraproject.org/rpms/blender/blob/8088da10c20e53ab0e1dd5de6fd3a2344bd288aa/f/blender.spec#_207
> >
> > So does prusa-slicer:
> >
> >
> > https://src.fedoraproject.org/rpms/prusa-slicer/blob/44359e4b53c503cb61a60842abf991a01d1cb9db/f/prusa-slicer.spec#_68
> >
> > Packages depending directly on openvdb are:
> >
> > $ fedrq wrsrc -s openvdb
> > OpenImageIO-2.4.17.0-1.fc40.src
> > blender-1:4.0.2-1.fc40.src
> > luxcorerender-2.7-0.10.beta1.fc40.src
> > openvkl-2.0.0-5.fc40.src
> > prusa-slicer-2.4.2-13.fc40.src
> > usd-23.11-2.fc40.src
> >
> > Of these, it looks like only OpenImageIO builds on i686. Packages
> > depending on it are:
> >
> > $ fedrq wrsrc -s OpenImageIO
> > OpenColorIO-2.2.1-6.fc40.src
> > blender-1:4.0.2-1.fc40.src
> > embree-4.3.0-2.fc40.src
> > luxcorerender-2.7-0.10.beta1.fc40.src
> > oidn-2.1.0-1.fc40.src
> > openshadinglanguage-1.12.14.0-9.fc40.src
> > usd-23.11-2.fc40.src
> >
> > Of those, only OpenColorIO builds on i686. Packages depending on it are:
> >
> > $ fedrq wrsrc -s OpenColorIO
> > OpenImageIO-2.4.17.0-1.fc40.src
> > blender-1:4.0.2-1.fc40.src
> > calligra-3.2.1-25.fc39.src
> > krita-5.2.2-1.fc40.src
> > luxcorerender-2.7-0.10.beta1.fc40.src
> > usd-23.11-2.fc40.src
> >
> > Of those, only calligra builds on i686, and it’s a leaf package. So, if
> > I haven’t missed anything, as long as i686 support is dropped from all
> > of calligra, OpenColorIO, OpenImageIO, and openvdb, then it should be OK.
> >  
> 
> Well I just re-tried openvdb with _smp_build_ncpus 1 and it still failed so
> I don't think we have a choice at this point. Perhaps it was hitting the
> 4GB max per process due to being 32bit?

yes, it could be. Another workaround is to reduce the debuginfo level,
if not done already, eg. from -g to -g1 (or even -g0)


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: rawhide aarch64 Thunderbird FTBFS "internal compiler error: Segmentation fault"

[Dan Horák]

On Thu, 25 Jan 2024 11:03:21 +
Peter Robinson  wrote:

> Hi,
> 
> > Tried twice, same error, aarch64 build bails out with
> 
> There's at least one known ICE on aarch64 for gcc-14 so I suggest
> checking if it looks related.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2259937

and I have opened https://bugzilla.redhat.com/show_bug.cgi?id=2260321
for EFL a moment ago


Dan

> 
> > | 34:29.97 *** WARNING *** there are active plugins, do not report this as 
> > a bug unless you can reproduce it without enabling any plugins.
> > | 34:29.97 Event| Plugins
> > | 34:29.97 PLUGIN_FINISH_UNIT   | annobin: Generate final 
> > annotations
> > | 34:29.97 PLUGIN_START_UNIT| annobin: Generate global 
> > annotations
> > | 34:29.97 PLUGIN_ALL_PASSES_START  | annobin: Generate 
> > per-function annotations
> > | 34:29.97 PLUGIN_ALL_PASSES_END| annobin: Register 
> > per-function end symbols
> > | 34:29.97 during RTL pass: split1
> > | 34:29.97 In file included from 
> > /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/core/SkOpts.cpp:43:
> > | 34:29.97 
> > /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/opts/SkBlitMask_opts.h:
> >  In function ‘void neon::blit_mask_d32_a8(SkPMColor*, size_t, const 
> > SkAlpha*, size_t, SkColor, int, int)’:
> > | 34:29.97 
> > /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/opts/SkBlitMask_opts.h:234:1:
> >  internal compiler error: Segmentation fault
> > | 34:29.97   234 | }
> > | 34:29.97   | ^
> > | 34:30.04 Please submit a full bug report, with preprocessed source (by 
> > using -freport-bug).
> > | 34:30.04 See  for instructions.
> >
> > I'm not going to jump through hoops there.
> > All other platforms finished the build fine, f39 and f38 builds
> > completed also for aarch64.
> >
> > See https://kojipkgs.fedoraproject.org//work/tasks/9052/112279052/build.log 
> > of
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=112279052 of
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=112278913
> >
> >   Eike
> >
> > --
> > GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 
> > 2D3A
> > --
> > ___
> > 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
--
___
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: Interesting difference between Koji and COPR (_isa macro)

[Dan Horák]

On Wed, 24 Jan 2024 17:56:40 +0100
Lumír Balhar  wrote:

> Hello.
> 
> Today I found out an interesting difference between Koji and COPR. 
> autowrap package has this in its specfile:
> 
> Requires: python%{python3_pkgversion}-Cython%{?_isa}
> 
> Which is incorrect for noarch package but hold on. The resulting package 
> from Koji requires:
> 
> python3-Cython
> 
> but in COPR, the result requires:
> 
> python3-Cython(x86-64)
> 
> and that breaks subsequent builds in COPR because python3-Cython does 
> not provide python3-Cython(x86-64).
> 
> In other words, if I rebuild autowrap in COPR and some other build later 
> tries to install it, the installation fails because nothing provides 
> python3-Cython(x86-64).
> 
> It seems like %{?_isa} is not defined for noarch packages in Koji but it 
> is in COPR. Is that a known problem/feature?

it could be because COPR always does an archful build (like plain mock
builds do), while koji knows noarch is a separate arch


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: HEADSUP boost and tbb rebuilds starting in a side tag

[Dan Horák]

On Thu, 18 Jan 2024 22:15:18 +
Jonathan Wakely  wrote:

> On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
> >
> > I'll be building boost, tbb, and the packages that depend on them in
> > the f40-build-side-81691
> > side tag over the next few hours (in advance of the mass rebuild tomorrow).
> >
> > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > don't rebuild it in rawhide, we're building it in the side tag and
> > will merge it back to rawhide. If you need to update your package
> > before the mass rebuild, please let me and Patrick (CC'd) know and
> > your changes can be built in the side tag too.
> >
> > (Since there is overlap between the packages that depend on boost and
> > tbb I'm doing them all at once)
> > https://fedoraproject.org/wiki/Changes/F40Boost183
> > https://fedoraproject.org/wiki/Changes/F39TBB2020.3  
> 
> Most of the packages have now been rebuilt and will be merged to
> rawhide soon (I hope!).
> See https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
> 
> The following packages failed to build, for the reasons shown. Some
> other packages that depend on these ones couldn't be built due to
> these failures. There are some others that weren't rebuild, like
> OpenImageIO and python-graph-tool, but the maintainers are aware.
> 
> 
> codeblocks
> needs non-existent squirrel-devel.i686

ah, we should have removed the dep after switching to the bundled
patched squirrel, fix in progress


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: Packed relative ELF relocations (DT_RELR) enabled by default in rawhide

[Dan Horák]

On Wed, 03 Jan 2024 10:47:12 +0100
Florian Weimer  wrote:

> This changed was originally planned and approved for Fedora 39.  It
> reduces startup time somewhat for large objects with lots of function
> and object pointers in global data.
> 
> It should be a transparent change, internal to the toolchain.  Within
> glibc itself, we started using this linker feature in glibc 2.36 (Fedora
> 37), and no issues surfaced.  A few dozen test rebuilds of core packages
> did not show any issues, either.

is
/usr/bin/ld: warning: -z pack-relative-relocs ignored
related? It seems to appear in s390x builds.


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: xmlParseMemory() and xmlParseMemory gone rawhide?

[Dan Horák]

On Sat, 18 Nov 2023 12:30:04 -0500
Steve Dickson  wrote:

> Hello,
> 
> When building an nfs-utils rpm in rawhide
> I get the following errors:
> 
> xml.c: In function ‘junction_parse_xml_buf’:
> xml.c:293:15: error: implicit declaration of function ‘xmlParseMemory’ 
> [-Werror=implicit-function-declaration]
>293 | tmp = xmlParseMemory(buf, (int)len);
>|   ^~
> xml.c:293:13: error: assignment to ‘xmlDocPtr’ {aka ‘struct _xmlDoc *’} 
> from ‘int’ makes pointer from integer without a cast 
> [-Werror=int-conversion]
>293 | tmp = xmlParseMemory(buf, (int)len);
>| ^
> xml.c: In function ‘junction_xml_write’:
> xml.c:390:9: error: ‘xmlIndentTreeOutput’ undeclared (first use in this 
> function)
>390 | xmlIndentTreeOutput = 1;
>| ^~~
> xml.c:390:9: note: each undeclared identifier is reported only once for 
> each function it appears in
> cc1: some warnings being treated as errors
> 
> Now I can build the upstream nfs-utils in rawhide, f39 and f38
> without a problem... It is only when I try to build a rawhide
> rpm that these errors happen. Any ideas??

https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2-parser.html
says xmlParseMemory() has been deprecated and thus probably not
available in the rawhide build of libxml2.


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: openmpi 5.0.0 update coming - drops i686 and C++ API

[Dan Horák]

On Tue, 07 Nov 2023 13:13:12 -
"David Bold"  wrote:

> Thanks Dan, I will have a go at your machine + mock to reproduce and debug.

I can confirm we have a problem, bout++-5.1.0-1 (latest in rawhide
branch) builds OK under F-38 mock, but fails in Rawhide mock. Some
tests won't complete, like being in deadlock or in an endless loop.


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: openmpi 5.0.0 update coming - drops i686 and C++ API

[Dan Horák]

On Tue, 07 Nov 2023 11:19:23 -
"David Bold"  wrote:

> > On Tue, 07 Nov 2023 10:17:06 -
> > David Schwörer  > 
> > 
> > if you mean strange as ppc64le, then it's in the output just because I
> > was updating a rawhide/ppc64le system, but the problem exists on all
> > arches. The libmpi_cxx.so.40 doesn't exist at all in openmpi 5.0, so
> > people on x86_64 or aarch64 are affected as well.
> > 
> > 
> > Dan
> 
> Sorry, I should have been more specific. I was taking about s390x, and only 
> remembered it is one of those once where I do no easy access to. Thus it is 
> hard for me to resolve it [0].

ah, I see, I will take a look if I can reproduce that locally, and I can
provide you access to our public s390x machine too.


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: openmpi 5.0.0 update coming - drops i686 and C++ API

[Dan Horák]

On Tue, 07 Nov 2023 10:17:06 -
David Schwörer  wrote:

> MUSIC is an independent package, that just happens to fail to build from 
> source after a new openmpi has been landed. bout++ is affected as well, and I 
> would be unhappy if it would be obsoleted by openmpi.
> 
> I think having more time to adapt dependent packages would have been helpful, 
> as I do not have the time right now to fix the issue on some strange 
> architecture, and I would assume MUSIC developer and maintainer also need 
> more time to port to a different API.

if you mean strange as ppc64le, then it's in the output just because I
was updating a rawhide/ppc64le system, but the problem exists on all
arches. The libmpi_cxx.so.40 doesn't exist at all in openmpi 5.0, so
people on x86_64 or aarch64 are affected as well.


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: openmpi 5.0.0 update coming - drops i686 and C++ API

[Dan Horák]

On Mon, 30 Oct 2023 07:48:38 -0600
Orion Poplawski  wrote:

> On 10/28/23 13:36, Orion Poplawski wrote:
> > I'm going to start building openmpi 5.0.0 and its requirements (pmix 
> > 4.2.7, prrte 3.0.2) and dependencies in a side-tag starting tomorrow. 
> > Notable changes are:
> > 
> > * Dropping support for 32-bit
> > * Dropping support for C++ API
> > * Change in the environment variable to allow oversubscription (running 
> > with more processes than available cores)
> > 
> > I will be making changes to dependent packages to address these changes.
> > 
> > I've been rebuilding deps in COPR 
> > (https://copr.fedorainfracloud.org/coprs/orion/pmix-4.2/builds/) and 
> > most rebuild fine.  One exception is MUSIC which depends on the C++ API. 
> >   There is a longstanding upstream issue to address this.  Hopefully 
> > this will finally get dealt with.
> > 
> > There are no soname bumps, but pmix has proved problematic in the past 
> > but its deps will be rebuilt.
> 
> The side tag has been merged.  I rebuilt all packages that depended on 
> libmpi_cxx.so - except MUSIC which needs upstream to drop it's 
> requirement on the C++ API.

this is causing broken deps in rawhide

 Problem 1: cannot install both openmpi-5.0.0-2.fc40.ppc64le from rawhide and 
openmpi-4.1.5-7.fc40.ppc64le from @System
  - package MUSIC-openmpi-1.1.16-13.20201002git8c6b77a.fc39.ppc64le from 
@System requires libmpi_cxx.so.40()(64bit)(openmpi-ppc64le), but none of the 
providers can be installed
  - cannot install the best update candidate for package 
openmpi-4.1.5-7.fc40.ppc64le
  - cannot install the best update candidate for package 
MUSIC-openmpi-1.1.16-13.20201002git8c6b77a.fc39.ppc64le

Couldn't openmpi Obsolete the MUSIC-openmpi subpackage?


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: mame validation time takes forever on rawhide/aarch64

[Dan Horák]

On Sun, 1 Oct 2023 14:21:23 +0200
Julian Sikorski  wrote:

> Am 01.10.23 um 10:17 schrieb Julian Sikorski:
> > Am 01.10.23 um 09:37 schrieb Dan Horák:
> >> On Sun, 1 Oct 2023 09:32:10 +0200
> >> Julian Sikorski  wrote:
> >>
> >>> Am 30.09.23 um 09:09 schrieb Julian Sikorski:
> >>>> Hello,
> >>>>
> >>>> mame package uses mame -validate as %check step. It has recently 
> >>>> started
> >>>> to cause problems on rawhide/aarch64:
> >>>> - I had to cancel 0.258 build after 16 hours [1]
> >>>> - 0.259 build is stuck since ca. 1600 UTC yesterday [2]
> >>>> Other branches built fine for aarch64, and so did other arches for
> >>>> rawhide. Additionally, there are no rawhide koschei builds since August
> >>>> making it harder to find the potential culprit.
> >>>> How can I investigate further? I might need to disable %check if the
> >>>> reason cannot be found.
> >>>>
> >>>> Best regards,
> >>>> Julian
> >>>>
> >>>> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404
> >>>> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762
> >>>
> >>> The build is still stuck. Do we have aarch64 machines accessible to
> >>> maintainers which could be used to see what the problem is? The last
> >>
> >> we do have, please see
> >> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> >>
> >>
> >>     Dan
> > 
> > Thanks! Unfortunately it appears that aarch64 is only available as f38 
> > and f37 which both finish the validation successfully. Rawhide is only 
> > available as x86_64 which does not exhibit the issue either.
> > I will see if doing a rawhide mock build on f38 host is sufficient. This 
> > is what koji seems to be doing anyway.
> > 
> > Best regards,
> > Julian
> 
> I managed to reproduce this on the aarch64 machine in mock. Validation 
> seems to get stuck right away at:
> 
> (gdb) bt
> #0  0xb5bddb08 in ___ZN4bgfx12VertexLayoutC1Ev_bti_veneer ()

hmm, couldn't it be related to the PAC & BTI feature [1]? I believe
someone mentioned some issues with it, probably here on the devel
list and the workaround was to disable the related compiler flags ...

> #1  0xf5870b2c in __libc_start_main_impl () from /lib64/libc.so.6
> #2  0xaef01570 in _start ()
> 
> One question: the binary in /builddir/build/BUILD still has symbols in, 
> correct?

yes, the files under /builddir/build/BUILDROOT/... are split into
stripped binaries and debuginfos
 
> Best regards,
> Julian

[1] https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication


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: mame validation time takes forever on rawhide/aarch64

[Dan Horák]

On Sun, 1 Oct 2023 09:32:10 +0200
Julian Sikorski  wrote:

> Am 30.09.23 um 09:09 schrieb Julian Sikorski:
> > Hello,
> > 
> > mame package uses mame -validate as %check step. It has recently started 
> > to cause problems on rawhide/aarch64:
> > - I had to cancel 0.258 build after 16 hours [1]
> > - 0.259 build is stuck since ca. 1600 UTC yesterday [2]
> > Other branches built fine for aarch64, and so did other arches for 
> > rawhide. Additionally, there are no rawhide koschei builds since August 
> > making it harder to find the potential culprit.
> > How can I investigate further? I might need to disable %check if the 
> > reason cannot be found.
> > 
> > Best regards,
> > Julian
> > 
> > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762
> 
> The build is still stuck. Do we have aarch64 machines accessible to 
> maintainers which could be used to see what the problem is? The last 

we do have, please see
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers


Dan

> lines in the build log are (and have been for a while):
> 
> Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.cLY2Y2
> + umask 022
> + cd /builddir/build/BUILD
> + cd mame-mame0259
> + ./mame -validate
> 
> Best regards,
> Julian
> ___
> 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: Build does not finish

[Dan Horák]

On Fri, 15 Sep 2023 19:01:07 +0200
"Kai A. Hiller"  wrote:

> Hello,
> 
> I started a build with `fedpkg build`, but after 43h and counting I 
> don‘t think it will finish anymore. Is there a way to terminate the 
> build? The build is 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=106154761

seems it hangs in the %check phase, probably it can't deal with the
massive system with 224 cpus ...

for termination you can use "koji cancel "


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: Automate your Fedora package maintenance using Packit

[Dan Horák]

On Fri, 15 Sep 2023 16:02:04 +0200
Frantisek Lachman  wrote:

> Thanks Dan and Daniel for the responses. You both are right. For our
> defence, this is always setup by an existing Fedora user (=human).
> 
> I can't speak of rel-eng (and honestly don't know) how problematic
> this "physical removal" on request is.

it's a process that at least 2 people must go thru, one opening a
ticket, second doing the removal and closing the ticket ...

> We can at least promote the licence check more
> and provide instructions on what to do if something does not fulfil the rules.
> (E.g. as a part of the issue Ankur created and mentioned
> (https://github.com/packit/packit/issues/2035))
> 
> Does anyone have any realistic solution (or an improvement) to this
> for Packit itself?
> 
> We can also stop uploading the source to the lookaside cache (or make
> it configurable),
> but the benefit of such automation is significantly reduced.

I think making it configurable could be the way, for example an upstream
project where I am the developer can have the upload enabled, because I
control my licensing situation, but it shouldn't be the default for a
"random" project.


        Dan

> František
> 
> 
> On Fri, Sep 15, 2023 at 3:39 PM Dan Horák  wrote:
> >
> > On Fri, 15 Sep 2023 15:13:58 +0200
> > Frantisek Lachman  wrote:
> >
> > > Hi Petr,
> > >
> > > we would like to avoid storing the archive in the lookaside cache before
> > > approving but the problem is that the CI on the PR (mainly the scratch
> > > build) does not work without the archive being in the lookaside cache
> > > already. Once this becomes possible, we (=Packit) would be happy to do 
> > > this
> > > only when approved.
> > >
> > > But thanks to the archive hash, we don't build anything to Fedora that is
> > > not approved.
> >
> > but this is the problem, once uploaded, it can be reached and
> > downloaded, making Fedora distributing the content. It then needs
> > a rel-eng action to "physically" remove problematic source archive.
> >
> >
> > 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
> ___
> 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: Automate your Fedora package maintenance using Packit

[Dan Horák]

On Fri, 15 Sep 2023 15:39:50 +0200
Frantisek Lachman  wrote:

> Thanks Vít for the link!
> 
> I am honestly not sure how CI should do this (and don't want to be the
> one who decides..;)
> 
> If CI does not need to have the source in the lookaside cache, Packit
> does not need to store anything in the lookaside cache (that's a good
> thing), but the maintainer can't be sure that the CI uses the same
> archive as Koji when building the package. (And someone needs to
> upload the archive into the lookaside archive later on.)

copr is able to download the sources using the SourceX tags before
building, if they use https. It is sufficient to have just the spec in a
git repo.


Dan

 
> František
> 
> On Fri, Sep 15, 2023 at 3:23 PM Vít Ondruch  wrote:
> >
> > I was proposing some methods how to enable download of sources for e.g. CI 
> > purposes here:
> >
> > https://pagure.io/packaging-committee/issue/1132#comment-769233
> >
> > But without too much success.
> >
> > But of course, CI could also be improved to download the required sources, 
> > if there is proper source URL.
> >
> >
> > Vít
> >
> >
> > Dne 15. 09. 23 v 15:13 Frantisek Lachman napsal(a):
> >
> > Hi Petr,
> >
> > we would like to avoid storing the archive in the lookaside cache before 
> > approving but the problem is that the CI on the PR (mainly the scratch 
> > build) does not work without the archive being in the lookaside cache 
> > already. Once this becomes possible, we (=Packit) would be happy to do this 
> > only when approved.
> >
> > But thanks to the archive hash, we don't build anything to Fedora that is 
> > not approved.
> >
> > If anyone has any better solution we're happy to improve. We also try to 
> > avoid Packit having too many permissions.
> >
> > František
> > (as a Packit PO)
> >
> > On Fri, Sep 15, 2023 at 1:25 PM Petr Pisar  wrote:
> >>
> >> V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
> >> > Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
> >> > automatically
> >>
> >> Did you know that a license review must precede uploading to Fedora 
> >> dist-git
> >> lookaside cache? The reason is once the archive is uploaded, Fedora
> >> distributes it.
> >>
> >> -- Petr
> >>
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >> 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
> >
> > ___
> > 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
___
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: Automate your Fedora package maintenance using Packit

[Dan Horák]

On Fri, 15 Sep 2023 15:13:58 +0200
Frantisek Lachman  wrote:

> Hi Petr,
> 
> we would like to avoid storing the archive in the lookaside cache before
> approving but the problem is that the CI on the PR (mainly the scratch
> build) does not work without the archive being in the lookaside cache
> already. Once this becomes possible, we (=Packit) would be happy to do this
> only when approved.
> 
> But thanks to the archive hash, we don't build anything to Fedora that is
> not approved.

but this is the problem, once uploaded, it can be reached and
downloaded, making Fedora distributing the content. It then needs
a rel-eng action to "physically" remove problematic source archive.


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: Will noarch packages "inherit" ExcludeArch from another noarch package

[Dan Horák]

On Wed, 13 Sep 2023 08:51:16 -0600
Jerry James  wrote:

> On Tue, Sep 12, 2023 at 10:02 PM Jerry James  wrote:
> > I looked at blueprint-compiler tonight, and found 2 bugs with the
> > handling of bitfields.  Sadly, fixing those still doesn't make the
> > test suite pass, so there is at least one more bug lurking somewhere.
> > Still, I think the package is probably fixable.  If you can wait just
> > a little longer, I will try to find the next bug tomorrow.
> 
> Bug 3 was on the line right next to bug 2. :-)  I have opened
> https://gitlab.gnome.org/jwestman/blueprint-compiler/-/merge_requests/143.
> That patch does not apply cleanly to version 0.6.0, but the attached
> version does.

as usually, great job, Jerry, thanks a lot


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: Will noarch packages "inherit" ExcludeArch from another noarch package

[Dan Horák]

On Tue, 12 Sep 2023 10:08:57 -0600
Jerry James  wrote:

> On Tue, Sep 12, 2023 at 10:03 AM Lyes Saadi  
> wrote:
> > I have a noarch package which faces an issue with one of its arches
> > (s390x), and which happens to have multiple noarch packages depending on
> > it, and they won't build either if they were built on that same arch
> > (but, they will still work normally when installed on that arch). And
> > so, I plan on adding an ExcludeArch, as per
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_arch_specific_runtime_and_build_time_dependencies.
> >
> > But, I don't know if I need to also ask maintainers of every dependency
> > to add ExcludeArch themselves. Indeed, the guideline says :
> >  > You can limit both the architectures used to build a noarch package,
> > *and the repositories to which the built noarch package will be added*
> >
> > So, am I correct in assuming that if my noarch package uses ExcludeArch,
> > every other dependent package, when building, will not build on that
> > Arch as well ?
> 
> You will indeed have to ask the maintainers of consuming packages to
> add that ExcludeArch too.  What package is it and what is the nature
> of the problem on s390x?  Maybe it can be fixed.

I believe it's about blueprint-compiler, which has some big endian
issues, please see https://bugzilla.redhat.com/show_bug.cgi?id=2169892


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: rawhide buildroot seems weird state, Child return code was: 255

[Dan Horák]

On Sat, 2 Sep 2023 21:07:07 +0900
Mamoru TASAKA  wrote:

> Hello, all:
> 
> Looks like currently rawhide buildroot seems weird state, mainly
> on ppc64le, but sometimes also on other arches:
> 
> e.g.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=105650426

^^^ nothing suspicious in the journal on the builder AFAICT ...


Dan

> https://koji.fedoraproject.org/koji/taskinfo?taskID=105642860
> https://koji.fedoraproject.org/koji/taskinfo?taskID=105653203
> https://koji.fedoraproject.org/koji/taskinfo?taskID=105626199
> 
> task result says:
> mock exited with status 30;
> 
> root.log says something like:
> 
> DEBUG util.py:539:  Executing command: ['/usr/bin/systemd-nspawn', '-q', 
> '-M', 'f0f2c583a3dc478b9a6fa5bc92ca54b5', '-D', 
> '/var/lib/mock/f40-build-45240825-5393892-bootstrap/root', '-a', 
> '--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.4xyubvar:/etc/resolv.conf', '--console=pipe', 
> '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
> '--setenv=HOME=/var/lib/mock/f40-build-45240825-5393892/root/installation-homedir',
>  '--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin', 
> '--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"', 
> '--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=C.UTF-8', 
> '--setenv=LC_MESSAGES=C.UTF-8', '--resolv-conf=off', '/usr/bin/dnf-3', 
> 'builddep', '--installroot', 
> '/var/lib/mock/f40-build-45240825-5393892/root/', 
> '--setopt=install_weak_deps=0', '--disableplugin=local', 
> '--disableplugin=spacewalk', '--disableplugin=versionlock', 
> '/var/lib/mock/f40-build-45240825-5393892/root//builddir/build/SRPMS/powerdevil-5.27.7-3.fc40.src
 .rpm', '--setopt=tsflags=nocontexts'] with env {'TERM': 'vt100', 'SHELL': 
'/bin/bash', 'HOME': 
'/var/lib/mock/f40-build-45240825-5393892/root/installation-homedir', 
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 
'printf "\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 
'LANG': 'C.UTF-8', 'LC_MESSAGES': 'C.UTF-8', 'SYSTEMD_NSPAWN_TMPFS_TMP': '0', 
'SYSTEMD_SECCOMP': '0'} and shell False
> 
> Then:
> 
> DEBUG util.py:444:  Running transaction check
> DEBUG util.py:444:  Transaction check succeeded.
> DEBUG util.py:444:  Running transaction test
> DEBUG util.py:444:  Transaction test succeeded.
> DEBUG util.py:444:  Running transaction
> DEBUG util.py:595:  Child return code was: 255
> 
> This does not look like BuildRequires dependency resolution failure, but some
> other "generic" issue.
> 
> Is this phenomenon being tracked on?
> 
> Regards,
> Mamoru
>   
> ___
> 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

bodhi and testing farm disagrees on test result

[Dan Horák]

Hi,

seems there is an issue with the test results presented in bodhi, please
see https://bodhi.fedoraproject.org/updates/FEDORA-2023-94f22746e1

bodhi thinks fedora-ci.koji-build.rpmdeplint.functional failed (it's
"red"), but when I click on the test in bodhi testing farm say "passed".

What can be wrong?


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: Several questionable packages installed on fresh system

[Dan Horák]

On Mon, 10 Jul 2023 10:38:18 +0200
Vít Ondruch  wrote:

> Hi,
> 
> I have recently installed Fedora Rawhide via netinstall and there are 
> some questionable packages installed by default, such as:
> 
> cpp
> libtomcrypt
> libxcrypt-compat
> exiv2
> 
> and I wonder what is the mechanism, which pulls these in? For example, 
> there is not much what would depend on cpp:
> 
> ~~~
> $ sudo dnf repoquery --whatdepends cpp
> Updating and loading repositories:
> Repositories loaded.
> NsCDE-0:2.2-2.fc38.x86_64
> buildah-0:1.30.0-1.fc39.x86_64
> calendar-0:1.37-7.20211220cvs.fc37.x86_64
> gcc-0:13.1.1-4.fc39.x86_64
> xrdb-0:1.2.1-5.fc38.x86_64
> ~~~

in such case I am trying to uninstall such packages and see what else
will dnf report as to-be-removed


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: %autorelease and arbitrary suffix

[Dan Horák]

On Wed, 21 Jun 2023 13:24:53 +0200
Fabio Valentini  wrote:

> On Wed, Jun 21, 2023 at 1:18 PM Dan Horák  wrote:
> >
> > On Wed, 21 Jun 2023 12:50:13 +0200
> > Sandro  wrote:
> >
> > > On 21-06-2023 10:51, Dan Horák wrote:
> > > > Hi,
> > > >
> > > > I have met a package that uses %autorelease and wanted to add a suffix
> > > > to the release for my local test build that doesn't have to be
> > > > compliant with the official versioning, but just differentiate interim
> > > > builds. It's quite common to append eg. ".rhbz123456" or similar
> > > > suffices. It looks to me that the current %autorelease doesn't allow
> > > > that per [1]. Did I miss something or should I file a RFE?
> > > >
> > > > [1] https://docs.pagure.org/fedora-infra.rpmautospec/autorelease.html
> > >
> > > I think '%autorelease -e rhbz123456' should do what you want.
> >
> > per the docs it adds the string into the "middle"
> >
> > I would like to achieve NVR like
> > systemd-250.10-2.fc36.rhbz123456
> >
> > which you do with
> > Release: 2%{?dist}.rhbz123456
> >
> > in the classic spec file
> 
> I think you should be able to do something like this:
> Release:   %{autorelease}.rhbz123456
> (I have not tested this since I'm not at my "work" machine right now).
> (Wrapping the %autorelease macro in {} is probably necessary to ensure
> the .rhbz123456 is not interpreted as an argument to the macro.)

thanks, that does it :-)

Wrote: /builddir/build/RPMS/systemd-253.5-3.fc38.rhbz123456.s390x.rpm


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: %autorelease and arbitrary suffix

[Dan Horák]

On Wed, 21 Jun 2023 12:50:13 +0200
Sandro  wrote:

> On 21-06-2023 10:51, Dan Horák wrote:
> > Hi,
> > 
> > I have met a package that uses %autorelease and wanted to add a suffix
> > to the release for my local test build that doesn't have to be
> > compliant with the official versioning, but just differentiate interim
> > builds. It's quite common to append eg. ".rhbz123456" or similar
> > suffices. It looks to me that the current %autorelease doesn't allow
> > that per [1]. Did I miss something or should I file a RFE?
> > 
> > [1] https://docs.pagure.org/fedora-infra.rpmautospec/autorelease.html
> 
> I think '%autorelease -e rhbz123456' should do what you want.

per the docs it adds the string into the "middle"

I would like to achieve NVR like
systemd-250.10-2.fc36.rhbz123456

which you do with
Release: 2%{?dist}.rhbz123456

in the classic spec file


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

%autorelease and arbitrary suffix

[Dan Horák]

Hi,

I have met a package that uses %autorelease and wanted to add a suffix
to the release for my local test build that doesn't have to be
compliant with the official versioning, but just differentiate interim
builds. It's quite common to append eg. ".rhbz123456" or similar
suffices. It looks to me that the current %autorelease doesn't allow
that per [1]. Did I miss something or should I file a RFE?

[1] https://docs.pagure.org/fedora-infra.rpmautospec/autorelease.html


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: LibreOffice packages

[Dan Horák]

On Thu, 15 Jun 2023 18:40:39 +0200
Miro Hrončok  wrote:

> On 01. 06. 23 22:16, Gwyn Ciesla via devel wrote:
> > I've taken ownership of libreoffice for the time being, at least to keep 
> > the lights on. Co-maintainers, as always, welcome.
> 
> Thanks.
> 
> Could you please prioritize making it build? The LibreOffice package fails to 
> build in rawhide for months. It's now blocking the Python 3.12 rebuild:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2215352
> 
> This is not directed only at Gwyn, but all the other folks who offered help.

for the record, the build failure is caused by a failing test, but it
doesn't show if it's the only problem there

...
Test name: DesktopLOKTest::testSignDocument_PEM_PDF
assertion failed
- Expression: bResult
Failures !!!

I believe we need a shared document to track who is doing what and
generally coordinate the actions.


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: Update squirrel to the latest version?

[Dan Horák]

On Mon, 12 Jun 2023 15:47:31 +0100
"Richard W.M. Jones"  wrote:

> On Sun, Jun 11, 2023 at 05:45:35PM -, Reon Beon via devel wrote:
> > Or is some software keeping it back?
> 
> Lack of people doing the work, usually.

that plus squirrel is being used by (at least) codeblocks, they had
plan to move forward, but I haven't reviewed the current state yet


Dan
 
> > See
> > https://release-monitoring.org/project/337515/
> 
> You can join and become a co-maintainer:
> 
> https://join.fedoraproject.org
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> ___
> 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: SIG proposal: libreoffice-sig

[Dan Horák]

On Tue, 06 Jun 2023 18:55:36 +
Mattia Verga via devel  wrote:

> I'm forking this proposal off from the other thread, as it got buried 
> under tons of posts.
> 
> Shall we set up a libreoffice-sig to coordinate and ensure that 
> libreoffice and all dependencies are properly maintained and updated as 
> RPMs? Are there enough users which, like me, don't like the idea to only 
> have LO available as a flatpak from an external service like Flathub and 
> would like to join forces to maintain it in RPM repos?

I am surely interested in the RPMs, mainly from the ppc64le (and s390x)
point of view. They are very unlikely to get flatpaks.


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: libftdi: Failure to create output directory (aarch64 only)

[Dan Horák]

On Tue, 6 Jun 2023 06:15:29 -0500
Richard Shaw  wrote:

> On Tue, Jun 6, 2023 at 4:17 AM Dan Horák  wrote:
> 
> > On Tue, 6 Jun 2023 11:00:39 +0200
> > Dominik 'Rathann' Mierzejewski  wrote:
> >
> > > On Tuesday, 06 June 2023 at 10:55, Dan Horák wrote:
> > > > On Tue, 6 Jun 2023 09:50:09 +0200
> > > > Dan Horák  wrote:
> > > >
> > > > > On Mon, 5 Jun 2023 17:53:59 -0500
> > > > > Richard Shaw  wrote:
> > > > >
> > > > > > I just saw this[1] on the packager dashboard:
> > > > > >
> > > > > > error: Could not create output directory
> > > > > > /builddir/build/BUILD/libftdi1-1.5/redhat-linux-build/doc/xml
> > > > > >
> > > > > > Full log:
> > > > > >
> > https://kojipkgs.fedoraproject.org/work/tasks/5182/101845182/build.log
> > > > > >
> > > > > > Is this a known issue?
> > > > > >
> > > > > > [1]
> > https://koschei.fedoraproject.org/package/libftdi?collection=f39
> > > > >
> > > > > it is an interesting issue, because my fresh scratch build [2] runs
> > > > > well on aarch64, but fails on s390x with the same error as yours
> > > > > and with a different error on ppc64le ... I wonder if it could be a
> > > > > "parallel make" issue.
> > > > >
> > > > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=101861225
> > > >
> > > > I think it is a parallel make issue, with an explicit "-j1" the builds
> > > > are passing OK
> > > >
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=101862160
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=101862632
> > > >
> > > > Perhaps it explains also the previous failures seen by koschei ...
> > >
> > > Reporting these upstream is best. I've had a similar issue with INN for
> > > years, but it has been fixed:
> > > https://github.com/InterNetNews/inn/issues/206 .
> >
> > right, but the upstream mailing list looks like a black hole from a
> > contributor point of view. But thanks to the SUSE maintainer and
> > http://developer.intra2net.com/mailarchive/html/libftdi/2023/msg5.html
> > we have the fix I believe.
> >
> 
> Thanks all! I'm not the primary maintainer but I didn't remember having
> this issue in the past so didn't even think it would be a parallel make
> issue.

yeah, I think we were just lucky not seeing the issue earlier :-)


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: libftdi: Failure to create output directory (aarch64 only)

[Dan Horák]

On Tue, 6 Jun 2023 11:00:39 +0200
Dominik 'Rathann' Mierzejewski  wrote:

> On Tuesday, 06 June 2023 at 10:55, Dan Horák wrote:
> > On Tue, 6 Jun 2023 09:50:09 +0200
> > Dan Horák  wrote:
> > 
> > > On Mon, 5 Jun 2023 17:53:59 -0500
> > > Richard Shaw  wrote:
> > > 
> > > > I just saw this[1] on the packager dashboard:
> > > > 
> > > > error: Could not create output directory
> > > > /builddir/build/BUILD/libftdi1-1.5/redhat-linux-build/doc/xml
> > > > 
> > > > Full log:
> > > > https://kojipkgs.fedoraproject.org/work/tasks/5182/101845182/build.log
> > > > 
> > > > Is this a known issue?
> > > > 
> > > > [1] https://koschei.fedoraproject.org/package/libftdi?collection=f39
> > > 
> > > it is an interesting issue, because my fresh scratch build [2] runs
> > > well on aarch64, but fails on s390x with the same error as yours
> > > and with a different error on ppc64le ... I wonder if it could be a
> > > "parallel make" issue.
> > > 
> > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=101861225
> > 
> > I think it is a parallel make issue, with an explicit "-j1" the builds
> > are passing OK
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=101862160
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=101862632
> > 
> > Perhaps it explains also the previous failures seen by koschei ...
> 
> Reporting these upstream is best. I've had a similar issue with INN for
> years, but it has been fixed:
> https://github.com/InterNetNews/inn/issues/206 .

right, but the upstream mailing list looks like a black hole from a
contributor point of view. But thanks to the SUSE maintainer and
http://developer.intra2net.com/mailarchive/html/libftdi/2023/msg5.html
we have the fix I believe.


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: libftdi: Failure to create output directory (aarch64 only)

[Dan Horák]

On Tue, 6 Jun 2023 09:50:09 +0200
Dan Horák  wrote:

> On Mon, 5 Jun 2023 17:53:59 -0500
> Richard Shaw  wrote:
> 
> > I just saw this[1] on the packager dashboard:
> > 
> > error: Could not create output directory
> > /builddir/build/BUILD/libftdi1-1.5/redhat-linux-build/doc/xml
> > 
> > Full log:
> > https://kojipkgs.fedoraproject.org/work/tasks/5182/101845182/build.log
> > 
> > Is this a known issue?
> > 
> > [1] https://koschei.fedoraproject.org/package/libftdi?collection=f39
> 
> it is an interesting issue, because my fresh scratch build [2] runs
> well on aarch64, but fails on s390x with the same error as yours
> and with a different error on ppc64le ... I wonder if it could be a
> "parallel make" issue.
> 
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=101861225

I think it is a parallel make issue, with an explicit "-j1" the builds
are passing OK

https://koji.fedoraproject.org/koji/taskinfo?taskID=101862160
https://koji.fedoraproject.org/koji/taskinfo?taskID=101862632

Perhaps it explains also the previous failures seen by koschei ...


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: libftdi: Failure to create output directory (aarch64 only)

[Dan Horák]

On Mon, 5 Jun 2023 17:53:59 -0500
Richard Shaw  wrote:

> I just saw this[1] on the packager dashboard:
> 
> error: Could not create output directory
> /builddir/build/BUILD/libftdi1-1.5/redhat-linux-build/doc/xml
> 
> Full log:
> https://kojipkgs.fedoraproject.org/work/tasks/5182/101845182/build.log
> 
> Is this a known issue?
> 
> [1] https://koschei.fedoraproject.org/package/libftdi?collection=f39

it is an interesting issue, because my fresh scratch build [2] runs
well on aarch64, but fails on s390x with the same error as yours
and with a different error on ppc64le ... I wonder if it could be a
"parallel make" issue.

[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=101861225


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: ppc64le builds taking ages

[Dan Horák]

On Fri, 19 May 2023 16:27:23 +0200
Iñaki Ucar  wrote:

> Hi,
> 
> Do we know why some ppc64le builds take so much? And with "so much" I
> mean 7-10x the time for a "normal" run. Examples: 2 hours for [1] vs.
> 20 hours for [2].
> 
> And if we do know the cause, is there any way to predict it in order
> to avoid the %check section?
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=98395536
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=98395502

seems the build got restarted, perhaps due OOM on the builder, and
actual build time was 12h, perhaps the builder or the vmhost were
overloaded. Do you see the long build times in recent builds too? Both
examples are from March.


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: RPM 4.19 soname bump in Rawhide

[Dan Horák]

On Fri, 19 May 2023 12:24:15 +0200
Michal Domonkos  wrote:

> Hi all,
> 
> We're currently preparing an update to RPM 4.19 ALPHA for Rawhide in a
> side-tag.  The new version features a soname bump:
> 
> librpm.so.9 -> librpm.so.10
> librpmio.so.9 -> librpmio.so.10
> 
> The following packages link against the above libraries and thus will need to
> be rebuilt:
> 
> anaconda
> annobin
> fapolicyd
> frr
> gnome-software
> libappstream-glib
> libdnf-plugin-swidtags
> libextractor
> libzypp
> net-snmp
> openscap
> PackageKit
> perl-RPM2
> perl-RPM-VersionCompare
> php-pecl-rpminfo
> rpm-git-tag-sort
> rpm-ostree
> rpmreaper
> rust-blsctl
> rust-rpm-sequoia
> satyr
> supermin
> systemtap
> transactional-update

I guess the list comes from an x86 system, thus it is incomplete.
Please add s390utils there as well.


Dan

> 
> We would like to kindly ask the owners to issue a rebuild against our 
> side-tag.
> The command to do this is:
> 
> fedpkg build --target f39-build-side-67564
> 
> We already did scratch builds ourselves and the packages passing against the
> rawhide target also passed against the side-tag.
> 
> Please let us know if we can help with that or with any unexpected build
> failures.
> 
> Thank you!
> 
> -- 
> Michal Domonkos / RPM dev team / Red Hat, Inc.
> ___
> 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: linux-firmware RPM package

[Dan Horák]

On Sun, 30 Apr 2023 12:00:30 +0200
Matthias Weckbecker  wrote:

> Hi,
> 
> the linux-firmware package has recently added a requires in its spec for
> a bunch of other firmware packages: atheros-firmware, brcmfmac-firmware,
> mt7xxx-firmware, and realtek-firmware.
> 
> Is this intentional? I don't have hardware in my computer that requires
> the atheros firmware. It makes me slightly uneasy to install those blobs
> if I don't absolutely have to.

the new subpackages are the way how to leave the unneeded firmwares out,
similar to what was done for the GPU firmware earlier. There is nothing
new installed on your system, all files have been part of the main
linux-firmware rpm until now. To keep the upgrade path working the new
subpackages are "Requires" for F <= 38, but only "Recommends" for
F >= 39, see
https://src.fedoraproject.org/rpms/linux-firmware/c/be92a95e169422f1108bce0aee70ed96fc26fb0b?branch=rawhide
for details.


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: How to check if a package is retired?

[Dan Horák]

On Tue, 25 Apr 2023 10:57:56 +0200
Florian Weimer  wrote:

> * Peter Robinson:
> 
> > On Tue, Apr 25, 2023 at 8:56 AM Florian Weimer  wrote:
> >>
> >> The xorg-x11-drv-fbturbo is supposed to have been retired (see
> >> ).   How can I
> >> check if this is actually the case?
> >
> > It's not, if you look at the tags at the bottom there should be a red
> > check mark against the f39 tag:
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=20127
> >
> > I filed this issue at the time it has issues:
> > https://pagure.io/releng/issue/11388
> >
> > It's allegedly a problem here:
> > https://pagure.io/rpkg/issue/685
> >
> > II did actually note that in your bug report:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2187060#c6
> 
> Sorry, it's still not clear to me if the dead.package stuff is an
> optional step of retirement to reflect it in dist-git to make it more
> noticeable (if all you do is a fedpkg clone), or the core criteria for
> retirement.
> 
> Or put differently, if I want to fix this, can I just push a
> dead.package file myself, as a provenpackager?

there is "fedpkg retire" to retire a package, it will do a bit more
behind the scenes AFAIK


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: It’s time to transform the Fedora devel list into something new

[Dan Horák]

On Fri, 21 Apr 2023 10:31:04 +0300
Panu Matilainen  wrote:

> On 4/21/23 02:21, Simo Sorce wrote:
> > Hi Matthew, you say: "We're missing people", and I think, "who?".
> > And who are you going to miss if you move to discourse?
> > 
> > I will be candid, I tried to use forums since the old phpBB times, it
> > never works for me.
> > I have no time to go roaming over forums except if a search engine
> > brings me there.
> > 
> > The mailing list make messages land in my client, on which I am very
> > efficient, therefore I can check all messages once a day, and respond
> > if I find a worthy topic.
> > 
> > Unless this discourse has some great mail bridge (it doesn't) or maybe
> > an rss feed (I do not use those at work, but I guess I could ?) So that
> > I can skim messages on my terms, I think I (and those like me) will be
> > the next "missing people".
> 
> Ditto.

I am in the same boat, FWIW ...

> 
> I actually quite like Discourse - for a forum software - from experience 
> related to various freetime activities.
> 
> However, Discourse replacing mailing lists WILL be the end of habitually 
> skimming through everything that goes on devel (and a whole bunch of 
> other lists) to spot issues that might be of my concern. The result will 
> be in me being considerably less aware of what goes around in Fedora, 
> rpm related or not.


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: package WP-CLI needs update

[Dan Horák]

On Thu, 20 Apr 2023 09:20:27 +0200
Marius Schwarz  wrote:

> Hi,
> 
> package WP-CLI needs an update to 2.7.1 in all releases as in the 
> current state, it's useless.
> 
> A bugreport against the package is open since nov. 2022:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2148434

the maintainer hasn't been active in years if I see right, feel free to
take over the maintainership via
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/


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: Need help to build Blender 3.5.0

[Dan Horák]

On Thu, 30 Mar 2023 04:04:42 -
"Luya Tshimbalanga"  wrote:

> Hello team, 
> Blender 3.5.0 got released today at this time of writing. Unfortunately, 
> failure occurred with the following link possibly related to cycles:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=99301805
> 
> Can someone investigate the problem?

hmm, an internal compiler error on x86_64 (needs someone with x86 to
report a bug) and a missing dependency "pkgconfig(level-zero)"
on others


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: What happen kup in Fedora 37

[Dan Horák]

On Mon, 27 Mar 2023 11:35:43 -0400
Steve Dickson  wrote:

> Hello,
> 
> I'm trying to access kernel.org with kup
> script but it does not seem to be in Fedora 37.
> 
> The only rpm I can find is kup-0.3.6-11.fc36.rpm.
> 
> What am I missing??

no new maintainer was found for it after being orphaned, thus got
retired and removed, see
https://src.fedoraproject.org/rpms/kup/c/2e9e1f6c9c75a34801d8ea1b830591dca0635d23?branch=rawhide


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: c++ packaging of contour terminal and libunicode

[Dan Horák]

On Tue, 28 Feb 2023 11:04:27 +
Ian McInerney via devel  wrote:

> On Mon, Feb 27, 2023 at 12:21 PM Felix Wang  wrote:
> 
> > Thanks for your advice. I tried and it can be built with no error, but
> > when installing built contour package, it shows the following error:
> > ```
> > Error:
> >  Problem: conflicting requests
> >   - nothing provides libContourTerminalDisplay.so()(64bit) needed by
> > contour-20230226-1.fc39.x86_64
> >   - nothing provides libcrispy-core.so()(64bit) needed by
> > contour-20230226-1.fc39.x86_64
> > ```
> >  
> 
> This looks to be because upstream isn't installing those two shared
> libraries in their CMake steps, so the RPM isn't including them in its
> packaged files.

another option is to build the internal libs as static, then they won't
have to be installed. Try appending
-DBUILD_SHARED_LIBS:BOOL=OFF
to the cmake flags


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: openexr: Any s390x people in the house?

[Dan Horák]

On Tue, 14 Feb 2023 07:19:38 -0600
Richard Shaw  wrote:

> I currently have to disable tests for s390x[1] (and ppc64le) for likely
> endianess issues.
> 
> Troubleshooting these is more than a little outside of my wheelhouse.
> 
> I hate keeping them disabled so I wanted to see if anyone could spare a few
> cycles to investigate.

I will try to allocate some cycles for those


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: Planned Outage - s390x builders - 2023-02-10 08:00 UTC -> 22:00 UTC

[Dan Horák]

On Sat, 11 Feb 2023 09:37:08 +
"Richard W.M. Jones"  wrote:

> On Thu, Feb 09, 2023 at 11:35:14AM -0500, Stephen Smoogen wrote:
> > Affected Services:
> >
> > s390x koji builders. Jobs will queue up, but not be processed until
> > the builders are back online. Maintainers are urged to just avoid
> > submitting builds just before and during this outage.
> 
> Do we need to cancel & resubmit hanging jobs, eg:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=97341784

those are OK, they are waiting. When s390x builders are back up, they
will pick them and finish the builds.


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: Fedora 38 mass rebuild is finished

[Dan Horák]

On Wed, 8 Feb 2023 17:37:09 +0100
Dan Horák  wrote:

> On Wed, 08 Feb 2023 15:24:47 +
> Sérgio Basto  wrote:
> 
> > On Tue, 2023-01-31 at 12:03 +, Zbigniew Jędrzejewski-Szmek wrote:  
> > > On Mon, Jan 30, 2023 at 04:45:37PM -0800, Kevin Fenzi wrote:
> > > > On Tue, Jan 24, 2023 at 09:42:10AM +, Zbigniew Jędrzejewski-
> > > > Szmek wrote:
> > > > > On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:
> > > > > > On Mon, Jan 23, 2023 at 10:26:18PM +, Sérgio Basto wrote:
> > > > > > > 
> > > > > > > I found more 5 with
> > > > > > > https://koji.fedoraproject.org/koji/tasks?owner=releng=active=tree=all=-id
> > > > > > > 
> > > > > > > 96481236 build (f38-rebuild,
> > > > > > > /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
> > > > > > > 
> > > > > > > 96474133 build (f38-rebuild, /rpms/trace-
> > > > > > > cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
> > > > > > > 
> > > > > > > 96404064 build (f38-rebuild, /rpms/perl-
> > > > > > > SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
> > > > > > > 
> > > > > > > 96383273 build (f38-rebuild,
> > > > > > > /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
> > > > > > > 
> > > > > > > 96368979 build (f38-rebuild,
> > > > > > > /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1f
> > > > > > > f)
> > > > > > 
> > > > > > Yes, I have canceled all those now. 
> > > > > 
> > > > > I started builds for all of those now.
> > > > 
> > > > All of them have hung again after running since you started them. 
> > > > 
> > > > I think someone is going to need to try and build them in local
> > > > mock and
> > > > see where they are getting stuck. 
> > > > 
> > > > Can you cancel them again? Or would you like me to try and look and
> > > > see
> > > > what they are hung on?
> > > 
> > > I cancelled them now. All five were still hung.
> > > It's up to the maintainers to figure out what is going.
> > > E.g. yaksa was hanging in tests…
> > 
> > Any news about these packages that hang on koji ? we may include opencv
> > package on this list.
> > 
> > Last lines of build opencv on ppc64le are [1] and after we got 55385703
> > (55 millions) of lines with "mashing detected" message,  the log file
> > have 2,30G ! 
> > 
> > Also I see "buffer overflow detected ***: terminated cat: /symlink2-
> > fakechroot: No such file or directory " on fakechroot  
> 
> this looks weird, I am trying a local build

and they confirm the observation from koji, both a small and a big
machine produce tons of the error messages, but the build itself
finishes successfully. I will keep looking further.


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: Fedora 38 mass rebuild is finished

[Dan Horák]

On Wed, 08 Feb 2023 15:24:47 +
Sérgio Basto  wrote:

> On Tue, 2023-01-31 at 12:03 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Jan 30, 2023 at 04:45:37PM -0800, Kevin Fenzi wrote:  
> > > On Tue, Jan 24, 2023 at 09:42:10AM +, Zbigniew Jędrzejewski-
> > > Szmek wrote:  
> > > > On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:  
> > > > > On Mon, Jan 23, 2023 at 10:26:18PM +, Sérgio Basto wrote:  
> > > > > > 
> > > > > > I found more 5 with
> > > > > > https://koji.fedoraproject.org/koji/tasks?owner=releng=active=tree=all=-id
> > > > > > 
> > > > > > 96481236 build (f38-rebuild,
> > > > > > /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
> > > > > > 
> > > > > > 96474133 build (f38-rebuild, /rpms/trace-
> > > > > > cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
> > > > > > 
> > > > > > 96404064 build (f38-rebuild, /rpms/perl-
> > > > > > SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
> > > > > > 
> > > > > > 96383273 build (f38-rebuild,
> > > > > > /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
> > > > > > 
> > > > > > 96368979 build (f38-rebuild,
> > > > > > /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1f
> > > > > > f)  
> > > > > 
> > > > > Yes, I have canceled all those now.   
> > > > 
> > > > I started builds for all of those now.  
> > > 
> > > All of them have hung again after running since you started them. 
> > > 
> > > I think someone is going to need to try and build them in local
> > > mock and
> > > see where they are getting stuck. 
> > > 
> > > Can you cancel them again? Or would you like me to try and look and
> > > see
> > > what they are hung on?  
> > 
> > I cancelled them now. All five were still hung.
> > It's up to the maintainers to figure out what is going.
> > E.g. yaksa was hanging in tests…  
> 
> Any news about these packages that hang on koji ? we may include opencv
> package on this list.
> 
> Last lines of build opencv on ppc64le are [1] and after we got 55385703
> (55 millions) of lines with "mashing detected" message,  the log file
> have 2,30G ! 
> 
> Also I see "buffer overflow detected ***: terminated cat: /symlink2-
> fakechroot: No such file or directory " on fakechroot

this looks weird, I am trying a local build


Dan
 
> Best regards,
> 
> [1]
> https://koji.fedoraproject.org/koji/taskinfo?taskID=97209133
> 
> /usr/include/c++/13/bits/stl_vector.h:1142: std::vector<_Tp,
> _Alloc>::const_reference std::vector<_Tp,
> _Alloc>::operator[](size_type) const [with _Tp = float; _Alloc =  
> std::allocator; const_reference = const float&; size_type = long
> unsigned int]: Assertion '__n < this->size()' failed.
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** longjmp causes uninitialized stack frame ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> *** stack smashing detected ***: terminated
> 
> > Zbyszek
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > 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: 
> 

Re: Rawhide and debug kernel changes

[Dan Horák]

On Fri, 3 Feb 2023 08:03:10 -0600
Justin Forbes  wrote:

> On Fri, Feb 3, 2023 at 6:52 AM Dan Horák  wrote:
> >
> > On Thu, 2 Feb 2023 14:17:36 -0600
> > Justin Forbes  wrote:
> >
> > > As the MR is now merged, it is a good time to make sure that everyone
> > > is aware. As of 6.2-rc5, Rawhide is no longer forcing a debug build
> > > with any kernels. All rawhide kernels are now built just like stable
> > > Fedora kernels, with both non-debug and debug variations.   This
> > > change was necessary because performance has degraded with debug
> > > kernels to the point that there were very few people using them,
> > > meaning fewer people testing daily upstream development builds.
> > > Changing the config to make the performance acceptable to more would
> > > take away much of the usefulness of the debug builds to begin with.
> > > We do still appreciate those who have the patience and ability to run
> > > rawhide debug kernels when possible just because they do still find
> > > the occasional lockdep issue, or other problems that would be hidden
> > > by a non-debug kernel.
> > >
> > > In addition to this change, I have added debug builds for aarch64
> > > kernels.  Previously, debug kernels were only available on x86.
> >
> > do you plan to still populate the RawhideKernelNodebug repo with the
> > current kernel rcs for use on the stable releases?
> 
> I had planned to discontinue this, but I suppose I can continue if
> there is value in it.

yes, please. I find the weekly frequency of the rcs combined with stable
Fedoras as the right compromise to be able to provide some useful
feedback. Hopefully I am not alone :-)


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: Rawhide and debug kernel changes

[Dan Horák]

On Thu, 2 Feb 2023 14:17:36 -0600
Justin Forbes  wrote:

> As the MR is now merged, it is a good time to make sure that everyone
> is aware. As of 6.2-rc5, Rawhide is no longer forcing a debug build
> with any kernels. All rawhide kernels are now built just like stable
> Fedora kernels, with both non-debug and debug variations.   This
> change was necessary because performance has degraded with debug
> kernels to the point that there were very few people using them,
> meaning fewer people testing daily upstream development builds.
> Changing the config to make the performance acceptable to more would
> take away much of the usefulness of the debug builds to begin with.
> We do still appreciate those who have the patience and ability to run
> rawhide debug kernels when possible just because they do still find
> the occasional lockdep issue, or other problems that would be hidden
> by a non-debug kernel.
> 
> In addition to this change, I have added debug builds for aarch64
> kernels.  Previously, debug kernels were only available on x86.

do you plan to still populate the RawhideKernelNodebug repo with the
current kernel rcs for use on the stable releases?


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: Build stuck on ppc64le

[Dan Horák]

On Tue, 24 Jan 2023 12:07:10 +
"Richard W.M. Jones"  wrote:

> https://koji.fedoraproject.org/koji/taskinfo?taskID=96612861
> 
> The build has completed already on other arches, but on ppc64le it has
> been stuck for ~ 45 minutes.  What's especially odd is that it has
> apparently picked a builder (so it's not stuck waiting for a free
> machine) but the builder isn't making progress.

I think the builder is on a host that's not responding currently, I
will free the task, so another active builder can pick it up


Dan

> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.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
___
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 38 mass rebuild is finished

[Dan Horák]

On Mon, 23 Jan 2023 18:44:00 +
"Richard W.M. Jones"  wrote:

> On Mon, Jan 23, 2023 at 05:44:16PM +0100, Tomas Hrcka wrote:
> > Things still needing rebuilding
> > https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html  
> 
> What is the significance of packages that appear on this list?
> 
> ocaml-mysql appears there, and it does not look like a rebuild was
> attempted:
> https://koji.fedoraproject.org/koji/packageinfo?packageID=ocaml-mysql

this situation usually means the build failed in the "create SRPM from
dist-git" phase


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: Fedora 38 mass rebuild started

[Dan Horák]

On Thu, 19 Jan 2023 09:20:25 -
"Artur Frenszek-Iwicki"  wrote:

> So I'm sure this question has been asked during previous Mass Rebuilds,
> but I can't find the answer in the heaps of messages in my mailbox,
> so I'll ask again: if my package failed to build during the Mass Rebuild
> and I know how to fix it - I don't have to wait for the rebuilt to end,
> right? I can just go ahead, push the changes to dist-git and trigger a build.

right, no need to wait


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: fedpkg local - do not clean build directory

[Dan Horák]

On Mon, 16 Jan 2023 21:21:39 -0700
Orion Poplawski  wrote:

> How the #$@! do I get fedpkg local to not cleanup the local build 
> directory after a successful build?  This is the most annoying change to 
> come around in a long time IMHO.

hmm, it doesn't clean the build directory here (fedpkg-1.43-2.fc36)


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: Porting Fedora for the LoongArch architecture.

[Dan Horák]

On Wed, 11 Jan 2023 11:45:59 +0100
Gerd Hoffmann  wrote:

> On Wed, Jan 11, 2023 at 05:26:33PM +0800, Robin Lee wrote:
> > EDK2 support is also upstreamed but Fedora does not catch up.
> 
> There is no cross compiler (yet) in Fedora so I can hardly
> build edk2 firmware binaries ...
> 
> I expect that will change when the gcc-13 update lands in
> rawhide.

right now we have a FTBFS issue in cross-binutils after their rebase to
2.39. Once solved we can continue with cross-gcc and the LoongArch
PRs, which are pretty straightforward.


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: ImageMagick 7 is landing in Rawhide

[Dan Horák]

On Mon, 9 Jan 2023 06:46:59 -0500
Neal Gompa  wrote:

> On Mon, Jan 9, 2023 at 6:42 AM Neal Gompa  wrote:
> >
> > On Mon, Jan 9, 2023 at 6:30 AM Dan Horák  wrote:
> > >
> > > On Fri, 6 Jan 2023 16:34:29 -0500
> > > Neal Gompa  wrote:
> > >
> > > > Hey all,
> > > >
> > > > The initial rebase of ImageMagick to v7 is landing in Rawhide now:
> > > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-9d3e9afbfd
> > > >
> > > > Most packages in the reverse dependency chain were rebuilt, though a
> > > > few are still left to fix and will be addressed separately.
> > > >
> > > > The ones remaining are:
> > > >
> > > > * autotrace (contacting upstream planned)
> > > > * q (dead upstream, orphaned)
> > > > * vdr-scraper2vdr (maybe dead upstream?)
> > > > * vdr-skinnopacity (dead upstream)
> > > > * vdr-tvguide (dead upstream)
> > >
> > > the list is missing dmtx-utils now reported as FailsToInstall, which
> > > failed in your rebuild due
> > >
> > > No matching package to install: 'pkgconfig(Wand)'
> > >
> > > see https://koji.fedoraproject.org/koji/taskinfo?taskID=95776617
> > >
> > > Was there any change in this regard in the new ImageMagick?
> > >
> >
> > Ah, oops. I thought I had caught that and fixed it. It's
> > `pkgconfig(MagickWand)` now (which also works for IM6 too).
> >
> 
> This should be fixed now:
> https://src.fedoraproject.org/rpms/dmtx-utils/c/adc7f3d9733496edf6c9e90a1fced30e40052553
> 
> (As an aside, the sources already request via this name, so no source
> code adjustment required)

ack, thanks


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: ImageMagick 7 is landing in Rawhide

[Dan Horák]

On Fri, 6 Jan 2023 16:34:29 -0500
Neal Gompa  wrote:

> Hey all,
> 
> The initial rebase of ImageMagick to v7 is landing in Rawhide now:
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-9d3e9afbfd
> 
> Most packages in the reverse dependency chain were rebuilt, though a
> few are still left to fix and will be addressed separately.
> 
> The ones remaining are:
> 
> * autotrace (contacting upstream planned)
> * q (dead upstream, orphaned)
> * vdr-scraper2vdr (maybe dead upstream?)
> * vdr-skinnopacity (dead upstream)
> * vdr-tvguide (dead upstream)

the list is missing dmtx-utils now reported as FailsToInstall, which
failed in your rebuild due

No matching package to install: 'pkgconfig(Wand)'

see https://koji.fedoraproject.org/koji/taskinfo?taskID=95776617

Was there any change in this regard in the new ImageMagick?


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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Dan Horák]

On Tue, 3 Jan 2023 08:14:04 -0500
Stephen Smoogen  wrote:

> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > - fedpkg mockbuild
> > >
> > > But it doesn't work correctly (will always use Release: 1) if you run
> > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> >
> > "Doctor, it hurts when I do that."
> >
> > 'rpmbuild -bs' is broken. Don't use it.
> >
> >
> Could you please elucidate why the command that people have used for nearly
> 30 years and is the most documented on how to build rpms is broken? And how
> people should use instead when they may be dealing with an environment
> which doesn't allow fedpkg to work? [AKA I am working on a package which I
> want to submit for review so I need to build a @$@$% src RPM somehow and I
> am being told I can't use the built in command to do so]

I wonder whether we should start recommending "rpkg" instead of plain
"rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it
quite useful/powerful.


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

[EPEL-devel] Re: libmaxminddb removed from epel7

[Dan Horák]

On Tue, 03 Jan 2023 11:12:02 -
"Sebastian Albrecht"  wrote:

> Hi friends
> i am using the epel(7) repo in Amazon Linux 2 and since two weeks ago the 
> package libmaxminddb disappeared. Is this the right place to ask for why it 
> was removed from the repository. Is there some kind of a removal announcement 
> / change history list?

I believe it was removed from EPEL-7, because it's available in RHEL-7,
added in 7.7 if I see right.


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

[EPEL-devel] Re: claws-mail for EPEL-9

[Dan Horák]

On Tue, 13 Dec 2022 19:09:48 +0100
Dan Horák  wrote:

> On Tue, 13 Dec 2022 09:56:40 -0800
> Troy Dawson  wrote:
> 
> > Packages do not automatically get transferred over from epel7 to a newer
> > epel.  People have to request them.
> > Nobody has requested it for epel9.
> > https://docs.fedoraproject.org/en-US/epel/epel-package-request/
> 
> yeah, I know the process :-) It is an attempt to avoid duplication of
> efforts in case someone else has been looking into it earlier or if I
> should start opening the bugs.

and for the record, here we go -
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-228fbb434d


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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Dan Horák]

On Tue, 20 Dec 2022 10:22:03 -0500
Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> 
> 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 ==
> Add support for unified kernels images to Fedora.
> 
> == Owner ==
> * Name: [[User:kraxel| Gerd Hoffmann]]
> * Email: kra...@redhat.com
> 
> 
> == Detailed Description ==
> The goal is to move away from initrd images being generated on the
> installed machine.  They are generated while building the kernel
> package instead, then shipped as part of a unified kernel image.
> 
> A unified kernel image is an all-in-one efi binary containing kernel,
> initrd, cmdline and signature.  The secure boot signature covers
> everything, specifically the initrd is included which is not the case
> when the initrd gets loaded as separate file from /boot.

What platforms are going to be affected? Is it x86-64 only or does it
include aarch64 (as it's also using UEFI)? Are ppc64le and s390x out of
the current scope?


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: Openvdb 10.0.1 failed on ppc64 architecture

[Dan Horák]

On Thu, 15 Dec 2022 08:22:02 -
"Luya Tshimbalanga"  wrote:

> > On Fri, 2 Dec 2022 10:45:59 +0100
> > Dan Horák  > 
> >  db
> > 
> > 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
> > On Fri, 2 Dec 2022 10:45:59 +0100
> > Dan Horák  > 
> >  db
> > 
> > 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
> >   
> 
> The above line helped solving the issue.

thanks for the confirmation


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

[EPEL-devel] Re: claws-mail for EPEL-9

[Dan Horák]

On Tue, 13 Dec 2022 09:56:40 -0800
Troy Dawson  wrote:

> Packages do not automatically get transferred over from epel7 to a newer
> epel.  People have to request them.
> Nobody has requested it for epel9.
> https://docs.fedoraproject.org/en-US/epel/epel-package-request/

yeah, I know the process :-) It is an attempt to avoid duplication of
efforts in case someone else has been looking into it earlier or if I
should start opening the bugs.


Dan
 
> 
> On Tue, Dec 13, 2022 at 9:15 AM Dan Horák  wrote:
> 
> > Hi,
> >
> > isn't anybody already working on getting claws-mail to EPEL-9? My
> > initial assessment shows that it shouldn't be difficult
> > - add libetpan and ytnef, they are the missing BRs, both build OK from
> > fedora spec, neither is in RHEL
> > - add claws-mail, with some little tweaks it can use its fedora spec
> >
> >
> > Dan
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> >
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] claws-mail for EPEL-9

[Dan Horák]

Hi,

isn't anybody already working on getting claws-mail to EPEL-9? My
initial assessment shows that it shouldn't be difficult
- add libetpan and ytnef, they are the missing BRs, both build OK from
fedora spec, neither is in RHEL
- add claws-mail, with some little tweaks it can use its fedora spec


Dan
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-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

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: 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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Dan Horák]

On Tue, 01 Nov 2022 11:26:13 -
Daan De Meyer via devel  wrote:

> I've added a new section to the proposal with the benchmark results of some 
> benchmarks we performed against a Fedora 37 system built with frame pointers 
> and a regular Fedora 37 system. The impact on most benchmarks seems limited 
> aside from the CPython benchmark suite (pyperformance). See the proposal 
> itself for the details.

what is the impact of the proposed change on non-x86 platforms? I
assume the proposal focuses on x86, but the distro wide flags are shared
across all platforms in Fedora, it means aarch64, ppc64le and s390x.
With RISC-V waiting behind the door ...


Thanks,

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: error: 'std::shared_ptr' has not been declared

[Dan Horák]

On Mon, 24 Oct 2022 11:14:46 -
"Martin Gansser"  wrote:

> Hi,
> when compiling QMPlay2-22.10.23 [1] on f35 and f36 i get this error message:
> 
> [38/321] /usr/bin/g++ -DDBUS_SUSPEND -DNOTIFIES_FREEDESKTOP 
> -DQMPLAY2SHAREDLIB_LIBRARY -DQMPLAY2_LIBASS -DQT_CORE_LIB -DQT_DBUS_LIB 
> -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_QML_LIB -DQT_SVG_LIB 
> -DQT_USE_FAST_OPERATOR_PLUS -DQT_WIDGETS_LIB -DUSE_OPENGL -DUSE_QML 
> -DUSE_YOUTUBEDL -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS 
> -Dlibqmplay2_EXPORTS 
> -I/home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/redhat-linux-build/src/qmplay2 
> -I/home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2 
> -I/home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/redhat-linux-build/src/qmplay2/libqmplay2_autogen/include
>  -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz 
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
> -I/usr/include/sysprof-4 -I/usr/include/libxml2 -I/usr/include/fribidi 
> -I/usr/include/ffmpeg -isystem /usr/include/qt5 -isystem 
> /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem 
> /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtWidgets -isystem /usr/inc
 lude/qt5/Q
>  tSvg -isystem /usr/include/qt5/QtDBus -isystem /usr/include/qt5/QtQml 
> -isystem /usr/include/qt5/QtNetwork -Wall -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  -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -g 
> -fPIC -fPIC -std=gnu++14 -MD -MT 
> src/qmplay2/CMakeFiles/libqmplay2.dir/QMPlay2OSD.cpp.o -MF 
> src/qmplay2/CMakeFiles/libqmplay2.dir/QMPlay2OSD.cpp.o.d -o 
> src/qmplay2/CMakeFiles/libqmplay2.dir/QMPlay2OSD.cpp.o -c 
> /home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2/QMPlay2OSD.cpp
> FAILED: src/qmplay2/CMakeFiles/libqmplay2.dir/QMPlay2OSD.cpp.o 
> /usr/bin/g++ -DDBUS_SUSPEND -DNOTIFIES_FREEDESKTOP -DQMPLAY2SHAREDLIB_LIBRARY 
> -DQMPLAY2_LIBASS -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB 
> -DQT_QML_LIB -DQT_SVG_LIB -DQT_USE_FAST_OPERATOR_PLUS -DQT_WIDGETS_LIB 
> -DUSE_OPENGL -DUSE_QML -DUSE_YOUTUBEDL -D__STDC_CONSTANT_MACROS 
> -D__STDC_LIMIT_MACROS -Dlibqmplay2_EXPORTS 
> -I/home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/redhat-linux-build/src/qmplay2 
> -I/home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2 
> -I/home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/redhat-linux-build/src/qmplay2/libqmplay2_autogen/include
>  -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz 
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
> -I/usr/include/sysprof-4 -I/usr/include/libxml2 -I/usr/include/fribidi 
> -I/usr/include/ffmpeg -isystem /usr/include/qt5 -isystem 
> /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem 
> /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtWidgets -isystem 
> /usr/include/qt5/
 QtSvg -isy
>  stem /usr/include/qt5/QtDBus -isystem /usr/include/qt5/QtQml -isystem 
> /usr/include/qt5/QtNetwork -Wall -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  -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -g 
> -fPIC -fPIC -std=gnu++14 -MD -MT 
> src/qmplay2/CMakeFiles/libqmplay2.dir/QMPlay2OSD.cpp.o -MF 
> src/qmplay2/CMakeFiles/libqmplay2.dir/QMPlay2OSD.cpp.o.d -o 
> src/qmplay2/CMakeFiles/libqmplay2.dir/QMPlay2OSD.cpp.o -c 
> /home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2/QMPlay2OSD.cpp
> In file included from 
> /home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2/QMPlay2OSD.cpp:19:
> /home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2/QMPlay2OSD.hpp:74:53:
>  error: 'std::shared_ptr' has not been declared
>74 | static std::unique_lock 
> ensure(std::shared_ptr );
>   | ^~
> /home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2/QMPlay2OSD.hpp:74:63:
>  error: expected ',' or '...' before '<' token
>74 | static std::unique_lock 
> ensure(std::shared_ptr );
>   |   ^
> /home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2/QMPlay2OSD.hpp:174:37:
>  error: 'shared_ptr' is not a member of 'std'
>   174 | using QMPlay2OSDList = QVector>;
>   | ^~
> /home/martin/rpmbuild/BUILD/QMPlay2-22.10.23/src/qmplay2/QMPlay2OSD.hpp:30:1: 
> note: 'std::shared_ptr' is defined in header ''; did you forget to 
> '#include '?
>29 | #include 
>   +++ |+#include 
>30 | 
> 

Re: What do do with failed f37 updates?

[Dan Horák]

On Mon, 24 Oct 2022 04:57:20 +0200
Alexander Ploumistos  wrote:

> On Mon, Oct 24, 2022 at 4:46 AM Richard Shaw  wrote:
> >
> > Is some sort of manual intervention required or not?
> >
> > Do I need to put in a ticket somewhere or not?
> >
> > Nothing in the message gives me any context as to what is required.
> 
> There's nothing to do, but wait.
> https://docs.fedoraproject.org/en-US/releases/lifecycle/#_development_process

the docs doesn't talk about gating, I have received the same messages
("gating failed" first, then "ignored", but no details why), hopefully
someone familiar with these process details will reply here :-)
Otherwise we should wait for the end of final freeze.


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: Koji issue: tagBuild failed: OSError: [Errno 30] Read-only file system: '/var/tmp/koji/tasks/6716'

[Dan Horák]

On Thu, 20 Oct 2022 09:50:45 +0200
Dan Horák  wrote:

> On Thu, 20 Oct 2022 09:32:06 +0200
> Milan Crha  wrote:
> 
> > Hi,
> > I searched for tagBuild mails here and one was from January, but it's
> > a) a long time ago; b) about something else.
> > 
> > This build:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=93236447
> > from today failed with:
> > 
> >   OSError: [Errno 30] Read-only file system: '/var/tmp/koji/tasks/6716'
> > 
> > when tagging the build.
> > 
> > Who's in charge for such error, please? Or am I supposed to do anything
> > and if so, what that is precisely, please?
> 
> the builder running the tagBuild task is broken and needs fixing
> (at least a reboot). Filing a ticket in
> https://pagure.io/fedora-infrastructure/issues
> would be ideal, but email like this or a ping on IRC is usually
> sufficient.

there was another report on IRC, so I filed
https://pagure.io/fedora-infrastructure/issue/10950


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: Koji issue: tagBuild failed: OSError: [Errno 30] Read-only file system: '/var/tmp/koji/tasks/6716'

[Dan Horák]

On Thu, 20 Oct 2022 09:32:06 +0200
Milan Crha  wrote:

>   Hi,
> I searched for tagBuild mails here and one was from January, but it's
> a) a long time ago; b) about something else.
> 
> This build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=93236447
> from today failed with:
> 
>   OSError: [Errno 30] Read-only file system: '/var/tmp/koji/tasks/6716'
> 
> when tagging the build.
> 
> Who's in charge for such error, please? Or am I supposed to do anything
> and if so, what that is precisely, please?

the builder running the tagBuild task is broken and needs fixing
(at least a reboot). Filing a ticket in
https://pagure.io/fedora-infrastructure/issues
would be ideal, but email like this or a ping on IRC is usually
sufficient.


Dan
 
> Another build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=93236471
> , ran less than a minute after the broken one, worked with no problem.
>   Bye,
>   Milan
> ___
> 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: Missing qt6-webengine package

[Dan Horák]

On Tue, 18 Oct 2022 19:54:13 +0100
chedi toueiti  wrote:

> Sorry if this has been asked before (I didn't find any reference in the
> archives).
> 
> I noticed that the qt6-webengine package is missing, a bug has been filled
> since February with no answer (
> https://bugzilla.redhat.com/show_bug.cgi?id=2055135).
> 
> Is there any hope to have it packaged, and how can I help with that ?

see also https://pagure.io/fedora-kde/SIG/issue/127, so some progress
has been made


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: stuck s390x builds in koji

[Dan Horák]

On Tue, 11 Oct 2022 11:15:35 +0200
Dominik 'Rathann' Mierzejewski  wrote:

> Hi!
> It seems that s390x builds in koji are not progressing. At the time of
> writing, I can see ~150 s390x buildArch tasks in "free" state. I've
> opened https://pagure.io/releng/issue/11079 to track this issue.

and we should be running again at almost full capacity


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: stuck s390x builds in koji

[Dan Horák]

On Tue, 11 Oct 2022 11:27:52 +0200
Dominik Mierzejewski  wrote:

> On Tuesday, 11 October 2022 at 11:18, Luna Jernberg wrote:
> > On 10/11/22, Dominik 'Rathann' Mierzejewski  wrote:
> > > Hi!
> > > It seems that s390x builds in koji are not progressing. At the time of
> > > writing, I can see ~150 s390x buildArch tasks in "free" state. I've
> > > opened https://pagure.io/releng/issue/11079 to track this issue.
> >
> > This might be related:
> > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/CLWFDN22YDF65R33BB3ZRSZHBZOE2LCK/
> 
> I thought so, too, but all 30 s390x builders are showing up as Enabled
> and Ready:
> https://koji.fedoraproject.org/koji/hosts?arch=s390x=enabled=name=all=all

koji lies a bit, they are green, but the last "check-in time" is
yesterday


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: stuck s390x builds in koji

[Dan Horák]

On Tue, 11 Oct 2022 11:18:12 +0200
Luna Jernberg  wrote:

> This might be related:
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/CLWFDN22YDF65R33BB3ZRSZHBZOE2LCK/

right, the builders are not running yet


Dan
 
> On 10/11/22, Dominik 'Rathann' Mierzejewski  wrote:
> > Hi!
> > It seems that s390x builds in koji are not progressing. At the time of
> > writing, I can see ~150 s390x buildArch tasks in "free" state. I've
> > opened https://pagure.io/releng/issue/11079 to track this issue.
> >
> > Regards,
> > Dominik
> > --
> > Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> > There should be a science of discontent. People need hard times and
> > oppression to develop psychic muscles.
> > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > 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
___
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: openshadinglanguage failure on non x86_64

[Dan Horák]

On Mon, 10 Oct 2022 10:46:20 +0200
Dan Horák  wrote:

> On Mon, 10 Oct 2022 10:09:32 +0900
> Mamoru TASAKA  wrote:
> 
> > Luya Tshimbalanga wrote on 2022/10/10 2:46:
> > > Hello team,
> > > 
> > > openshadinglanguage 1.12.6.2 only successfully built on x86_64 
> > > architecture but failed on others due to the following errors:
> > > 
> > > In file included from 
> > > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec_pvt.h:42,
> > >   from 
> > > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec.cpp:12:
> > > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/include/OSL/mask.h:7:10:
> > >  fatal error: immintrin.h: No such file or directory
> > >      7 | #include 
> > >    |  ^
> > > compilation terminated.
> > > 
> > > 
> > > That "immintrin.h" is provided by both gcc and clang according to "dnf -C 
> > > repoquery --whatprovides */immintrin.h". Could someone investigate the 
> > > cause and provide a patch?
> > > 
> > > See https://koji.fedoraproject.org/koji/taskinfo?taskID=92833862
> > > 
> > > Thanks in advance
> > > 
> > 
> > Well, gcc immintrin.h is 
> > "/usr/lib/gcc/x86_64-redhat-linux/12/include/immintrin.h" (note that 
> > "x86_64-" path).
> > 
> > And clang immintrin.h "/usr/lib64/clang/15.0.0/include/immintrin.h" says:
> > --
> > #if !defined(__i386__) && !defined(__x86_64__)
> > #error "This header is only meant to be used on x86 and x64 architecture"
> > #endif
> > --
> > 
> > AFAIK immintrin.h is available only on x86 / x86_64.
> > 
> > Then as far as I looked at src/include/OSL/mask.h, it looks like actually 
> > this supports non-x86 architectures
> > (as I see #elif defined(__GNUC__) || defined(__clang__) or so),
> > so just try to guard the inclusion like
> > 
> > #if defined(__i386__) || defined(__x86_64__)
> > #include 
> > #endif
> > 
> > and see how it goes. Maybe some additional modification is needed, but for 
> > now I expect that
> > most things may go well.
> 
> if I see right, then the reason for the inclusion of "immintrin.h" is to
> provide popcount and coutr_zero implementations when built with C++
> standard below C++20, see
> https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/blob/main/src/include/OSL/mask.h#L18
> or when not using GCC or clang where the functions are "builtin". So
> the inclusion is made from a wrong place. I am going to submit a PR to
> upstream.

https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/1605
should be the proper fix


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: openshadinglanguage failure on non x86_64

[Dan Horák]

On Mon, 10 Oct 2022 10:09:32 +0900
Mamoru TASAKA  wrote:

> Luya Tshimbalanga wrote on 2022/10/10 2:46:
> > Hello team,
> > 
> > openshadinglanguage 1.12.6.2 only successfully built on x86_64 architecture 
> > but failed on others due to the following errors:
> > 
> > In file included from 
> > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec_pvt.h:42,
> >   from 
> > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec.cpp:12:
> > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/include/OSL/mask.h:7:10:
> >  fatal error: immintrin.h: No such file or directory
> >      7 | #include 
> >    |  ^
> > compilation terminated.
> > 
> > 
> > That "immintrin.h" is provided by both gcc and clang according to "dnf -C 
> > repoquery --whatprovides */immintrin.h". Could someone investigate the 
> > cause and provide a patch?
> > 
> > See https://koji.fedoraproject.org/koji/taskinfo?taskID=92833862
> > 
> > Thanks in advance
> > 
> 
> Well, gcc immintrin.h is 
> "/usr/lib/gcc/x86_64-redhat-linux/12/include/immintrin.h" (note that 
> "x86_64-" path).
> 
> And clang immintrin.h "/usr/lib64/clang/15.0.0/include/immintrin.h" says:
> --
> #if !defined(__i386__) && !defined(__x86_64__)
> #error "This header is only meant to be used on x86 and x64 architecture"
> #endif
> --
> 
> AFAIK immintrin.h is available only on x86 / x86_64.
> 
> Then as far as I looked at src/include/OSL/mask.h, it looks like actually 
> this supports non-x86 architectures
> (as I see #elif defined(__GNUC__) || defined(__clang__) or so),
> so just try to guard the inclusion like
> 
> #if defined(__i386__) || defined(__x86_64__)
> #include 
> #endif
> 
> and see how it goes. Maybe some additional modification is needed, but for 
> now I expect that
> most things may go well.

if I see right, then the reason for the inclusion of "immintrin.h" is to
provide popcount and coutr_zero implementations when built with C++
standard below C++20, see
https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/blob/main/src/include/OSL/mask.h#L18
or when not using GCC or clang where the functions are "builtin". So
the inclusion is made from a wrong place. I am going to submit a PR to
upstream.


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: Review Swaps to support Stellarium 1.0

[Dan Horák]

On Tue, 04 Oct 2022 16:14:08 +
Mattia Verga via devel  wrote:

> Il 04/10/22 17:46, Dan Horák ha scritto:
> > On Tue, 04 Oct 2022 15:34:37 +
> > Gwyn Ciesla via devel  wrote:
> >
> >> Hi! Stellarium 1.0 was just released, and it grew some dependencies. If 
> >> you'd be so kind as to review one or more of these, I'll review one or 
> >> more of yours.
> >>
> >> QXlsx https://bugzilla.redhat.com/show_bug.cgi?id=2131838
> >> CalcMySky https://bugzilla.redhat.com/show_bug.cgi?id=2131842
> >> indi https://bugzilla.redhat.com/show_bug.cgi?id=2132014
> > I have taken indi
> 
> INDI is already packaged, see "libindi".
> 
> I'm about to update it to the latest version (1.9.8).

I have vaguely recalled that we have something like "indi", but I
searched only for "indi", not for "*indi*" :-)

Taking QXlsx then ...


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: Review Swaps to support Stellarium 1.0

[Dan Horák]

On Tue, 04 Oct 2022 15:34:37 +
Gwyn Ciesla via devel  wrote:

> Hi! Stellarium 1.0 was just released, and it grew some dependencies. If you'd 
> be so kind as to review one or more of these, I'll review one or more of 
> yours.
> 
> QXlsx https://bugzilla.redhat.com/show_bug.cgi?id=2131838
> CalcMySky https://bugzilla.redhat.com/show_bug.cgi?id=2131842
> indi https://bugzilla.redhat.com/show_bug.cgi?id=2132014

I have taken indi and would appreciate a review for pageedit
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2131949), it
should be pretty straightforward


Dan

> 
> And if you're feeling really generous, this unrelated review:
> 
> libchipcard https://bugzilla.redhat.com/show_bug.cgi?id=2035958
> 
> Thanks in advance!
> 
> -- 
> Gwyn Ciesla
> she/her/hers
>  
> in your fear, seek only peace 
> in your fear, seek only love
> -d. bowie
> 
> 
> Sent with Proton Mail secure email.
___
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: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Dan Horák]

On Wed, 28 Sep 2022 05:36:01 +1000
David Airlie  wrote:

> On Wed, Sep 28, 2022 at 5:34 AM Michael Cronenworth  wrote:
> >
> > On 9/27/22 1:56 PM, David Airlie wrote:
> > > The patent licensing around H264/H265 is such that providing this
> > > could leave Red Hat and other Fedora distributors exposed to legal
> > > problems.
> >
> > How is Mesa violating H264/H265 patents? Mesa wasn't performing any patented
> > functionality.
> >
> > If simply handling the bitstream is a violation like you say then 
> > glibc/kernel could
> > be patent infringing with an open() call. Let's not get that silly.
> 
> The implicit IANAL is very clear here.

the topic has already been opened on the legal list in
https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/message/M4LTGLHY5JX42IHC45WNWB5FH2JIFMAS/


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: Explicit dependency on systemd-rpm-macros now required?

[Dan Horák]

On Fri, 16 Sep 2022 13:42:42 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Fri, Sep 16, 2022 at 03:35:29PM +0200, Florian Weimer wrote:
> > * Zbigniew Jędrzejewski-Szmek:
> > 
> > > So… we certainly don't want people having to declare the dependency
> > > manually everywhere.
> > 
> > The packaging guidelines seem to say that the manual dependency is
> > required, though.
> 
> Yeah, you need *some* dependency. But opencryptoki has
> BR:systemd-devel, and systemd-devel has R:systemd, which has the
> Requires(meta) under discussion. So an explicit BR:systemd-rpm-macros
> should be redundant.

the BR: systemd-devel in opencryptoki might be just a historical
relict, because it used to be required to define the various macros
(IIRC)


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: Fedora support for new aarch64 chip

[Dan Horák]

On Mon, 19 Sep 2022 05:31:38 -
"Hua Duy"  wrote:

> Hello all,
> 
> I need to install Fedora IoT to our chip but I realize that the 
> Fedora-IoT-ostree-aarch64-36-20220618.0.iso does not support our GPU driver 
> so we can't install it.
> 
> + Document about our chip: 
> https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwjetPb6iKD6AhVrqFYBHcmdAUkQFnoECA4QAQ=https%3A%2F%2Fwww.renesas.com%2Fus%2Fen%2Fproducts%2Fmicrocontrollers-microprocessors%2Frz-mpus%2Frzg2m-ultra-high-performance-microprocessors-arm-cortex-a57-and-arm-cortex-a53-cpus-3d-graphics-and-4k=AOvVaw3Ymgg6zOhVGXdomup7g4Ef
> 
> + This is our GPU driver: 
> https://github.com/renesas-rz/rz_linux-cip/tree/rz-5.10-cip1-rt1/drivers/gpu/drm/rcar-du
> 
> Could anyone help me with how I can integrate our GPU driver into OS? 

Fedora can only distribute drivers that are part of the official Linux
kernel tree.


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: Minizip renaming Fedora Change

[Dan Horák]

On Thu, 15 Sep 2022 13:10:41 +0200
Lukas Javorsky  wrote:

> Hi,
> 
> I just got a question about how should I track the removal of "Provides and
> Obsoletes" from the new minizip-ng package.
> 
> We've decided to remove them in Fedora 42, but it's impossible to remember
> to do it for 2 years.
> There is no way to file a Bugzilla to Fedora 42 yet.
> 
> Is there some place where I can track it and it will remind me to do it
> when Fedora 42 is finally rawhide?

put a comment in the specfile :-)


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: Package PAM not updating

[Dan Horák]

On Thu, 8 Sep 2022 16:21:53 +0200
Iker Pedrosa  wrote:

> Hi,
> 
> There's a PAM bugzilla 
> that complains about not being able to update to its latest version. There
> seems to be a mix of architectures (x86_64 and i686) for this package and
> its subpackages (pam and pam-libs).
> 
> Can someone help me solve the problem?

I have replied in the bug. Seems F-36 GA was released with pam.i386.rpm
in the repos, likely due a bug in the multilib handler. But F-36
updates have correctly only pam-devel and pam-libs available as i386
rpms, causing update issue, that can be fixed by passing
"--allowerasing" to "dnf update".


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: [rawhide]Failure for aarch64 on embree

[Dan Horák]

On Wed, 10 Aug 2022 23:25:57 -0700
Luya Tshimbalanga  wrote:

> Hello team,
> 
> The scratch build specifically failed on aarch64 architecture [1] with 
> the following line when updating to embree 3.13.4 (not yet committed):
> 
> cc1plus: error: unrecognized command-line option '-msse2'
> 
> What will be the modification to do in this case? Thanks in advance

I believe it should be reported upstream, their configuration mechanism
likely doesn't work. It detects NEON support, which implies arm/aarch64,
but still injects -msse2 to compiler flags and defines
EMBREE_TARGET_SSE2.


Dan

 
> Embree source: https://src.fedoraproject.org/rpms/embree
> 
> Reference:
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90691409
> 
> -- 
> Luya Tshimbalanga
> Fedora Design Team
> Fedora Design Suite maintainer
___
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: [rawhide] ICU upgrade to 71.1

[Dan Horák]

On Fri, 5 Aug 2022 09:57:58 -0700
Kevin Fenzi  wrote:

> On Fri, Aug 05, 2022 at 05:30:14PM +0200, Dan Horák wrote:
> > On Thu, 4 Aug 2022 16:55:15 +0200
> > Dan Horák  wrote:
> > 
> > > On Thu, 4 Aug 2022 23:46:44 +0900
> > > Mamoru TASAKA  wrote:
> > > 
> > > > Frantisek Zatloukal wrote on 2022/08/02 23:17:
> > > > > Hmm,
> > > > > 
> > > > > I am really sorry for this, I'd messed up a lot somehow.
> > > > > 
> > > > > I'll take a deeper look tomorrow morning, but from a quick look:
> > > > > - webkit is now being built against the new icu, passed on i686 of> 
> > > > > architectures, it'll hopefully be done before the next compose.
> > > > 
> > > > So looks like the rebuild of webkit2gtk3 won't finish on s390x -
> > > > even after 51 hours:
> > > > 
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=90394095
> > > > 
> > > > The above link says there are multiple buildroots. What does it mean?
> > > > s390x build is killed and repeated due to some specific issue on
> > > > s390x server?
> > > 
> > > usually the build killed and restarted due OOM, but this is weird as
> > > Michael's previous build finished in ~6 hours 
> > 
> > I have moved the task to another builder and it is finishing right now.
> > 
> > Kevin, seems the z/VM builders are now more performant than the KVM
> > ones ...
> 
> I do not think thats the case. The build you moved OOMed again after
> that I am pretty sure. 

yeah, I suspect you are right :-( although I think it got faster to the
OOM :-)
 
> So, I have rebalanced the kvm ones. 
> 
> before: 
> 
> 25 builders, 2 cpus and 13GB memory
> 
> after: 
> 
> 20 builders, 3 cpus and 17GB memory.
> 
> Hopefully that will make these larger builds more happy. 
> If not, we can adjust more.

I see 20-30% of steal time in the VM building webkit, which should mean
the hypervisor's capacity is at/over limit :-( It would benefit from
having more physical CPUs.


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: [rawhide] ICU upgrade to 71.1

[Dan Horák]

On Thu, 4 Aug 2022 16:55:15 +0200
Dan Horák  wrote:

> On Thu, 4 Aug 2022 23:46:44 +0900
> Mamoru TASAKA  wrote:
> 
> > Frantisek Zatloukal wrote on 2022/08/02 23:17:
> > > Hmm,
> > > 
> > > I am really sorry for this, I'd messed up a lot somehow.
> > > 
> > > I'll take a deeper look tomorrow morning, but from a quick look:
> > > - webkit is now being built against the new icu, passed on i686 of> 
> > > architectures, it'll hopefully be done before the next compose.
> > 
> > So looks like the rebuild of webkit2gtk3 won't finish on s390x -
> > even after 51 hours:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=90394095
> > 
> > The above link says there are multiple buildroots. What does it mean?
> > s390x build is killed and repeated due to some specific issue on
> > s390x server?
> 
> usually the build killed and restarted due OOM, but this is weird as
> Michael's previous build finished in ~6 hours 

I have moved the task to another builder and it is finishing right now.

Kevin, seems the z/VM builders are now more performant than the KVM
ones ...


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: [rawhide] ICU upgrade to 71.1

[Dan Horák]

On Thu, 4 Aug 2022 23:46:44 +0900
Mamoru TASAKA  wrote:

> Frantisek Zatloukal wrote on 2022/08/02 23:17:
> > Hmm,
> > 
> > I am really sorry for this, I'd messed up a lot somehow.
> > 
> > I'll take a deeper look tomorrow morning, but from a quick look:
> > - webkit is now being built against the new icu, passed on i686 of> 
> > architectures, it'll hopefully be done before the next compose.
> 
> So looks like the rebuild of webkit2gtk3 won't finish on s390x -
> even after 51 hours:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=90394095
> 
> The above link says there are multiple buildroots. What does it mean?
> s390x build is killed and repeated due to some specific issue on
> s390x server?

usually the build killed and restarted due OOM, but this is weird as
Michael's previous build finished in ~6 hours 


Dan

 
> Regards,
> Mamoru
> 
> 
> > On Tue, Aug 2, 2022 at 4:04 PM Stephen Gallagher 
> > wrote:
> > 
> >> On Mon, Aug 1, 2022 at 6:04 PM Frantisek Zatloukal 
> >> wrote:
> >>>
> >>>
> >>>
> >>> On Mon, Aug 1, 2022 at 7:46 PM Stephen Gallagher 
> >> wrote:
> 
>  On Mon, Aug 1, 2022 at 5:20 AM Frantisek Zatloukal 
> >> wrote:
> >
> > Hi,
> >
> > Later today, I'll be starting with rebuilds of packages depending on
> >> icu. The rebuilds will take place in f37-build-side-55935 for all packages
> >> returned by sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list
> >> attached at the end of the message).
> >
> > Please, if you're going to make changes in affected packages before
> >> the side tag gets merged, make the build in the said side tag. I expect to
> >> merge the side tag with most of the affected packages built and then
> >> continue building things that take longer to build (webkit/libreoffice)
> >> later.
> >
> > For stuff that may fail to build, either due to newer icu or
> >> unrelated issues, there is a libicu69 compat package already available in
> >> rawhide, so that should take care of FTI issues that'd arise by merging the
> >> side tag. I'll try to help the maintainers with fixing the issues.
> >
> > I'll post updates to this thread as I progress with the bump.
> >
> > [0]
>  ...
> > v8
> >>>
> >>>
> >>> Yeah, I did a bunch of manual editing/checking up in the list, this
> >> should actually be v8-314.
> >>
> >>
> >> Apparently this side-tag has been merged and it broke a lot of stuff
> >> in Rawhide/ELN:
> >>
> >> 2022-08-02 13:20:21 [ERROR   ] Dependency check failed:
> >> 2022-08-02 13:20:21 [ERROR   ]  Problem 1: package
> >> anaconda-install-img-deps-37.11-2.eln120.ppc64le requires brltty, but
> >> none of the providers can be installed
> >> 2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
> >> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> >> libicuuc.so.69()(64bit) needed by brltty-6.5-4.eln120.ppc64le
> >> 2022-08-02 13:20:21 [ERROR   ]  Problem 2: package
> >> anaconda-widgets-37.11-2.eln120.ppc64le requires
> >> libgdk-3.so.0()(64bit), but none of the providers can be installed
> >> 2022-08-02 13:20:21 [ERROR   ]   - package
> >> anaconda-widgets-37.11-2.eln120.ppc64le requires
> >> libgtk-3.so.0()(64bit), but none of the providers can be installed
> >> 2022-08-02 13:20:21 [ERROR   ]   - package
> >> gtk3-3.24.34-2.eln120.ppc64le requires
> >> libtracker-sparql-3.0.so.0()(64bit), but none of the providers can be
> >> installed
> >> 2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
> >> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> >> libicui18n.so.69()(64bit) needed by
> >> libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
> >> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> >> libicuuc.so.69()(64bit) needed by
> >> libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
> >> 2022-08-02 13:20:21 [ERROR   ]  Problem 3: package
> >> nm-connection-editor-1.28.0-2.eln120.ppc64le requires
> >> libgdk-3.so.0()(64bit), but none of the providers can be installed
> >> 2022-08-02 13:20:21 [ERROR   ]   - package
> >> nm-connection-editor-1.28.0-2.eln120.ppc64le requires
> >> libgtk-3.so.0()(64bit), but none of the providers can be installed
> >> 2022-08-02 13:20:21 [ERROR   ]   - package
> >> gtk3-3.24.34-2.eln120.ppc64le requires
> >> libtracker-sparql-3.0.so.0()(64bit), but none of the providers can be
> >> installed
> >> 2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
> >> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> >> libicui18n.so.69()(64bit) needed by
> >> libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
> >> 2022-08-02 13:20:21 [ERROR   ]   - nothing provides
> >> libicuuc.so.69()(64bit) needed by
> >> libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
> >> 2022-08-02 13:20:21 [ERROR   ]  Problem 4: package
> >> anaconda-gui-37.11-2.eln120.ppc64le requires yelp, but none of the
> >> providers can be installed
> >> 2022-08-02 13:20:21 [ERROR   ]   - package
> >> anaconda-37.11-2.eln120.ppc64le requires anaconda-gui =
> >> 37.11-2.eln120, but none