Re: poppler soname bump in Rawhide soon
efl should be fixed in rawhide now. ~spot On Wed, Jan 31, 2024 at 7:32 AM Michael J Gruber wrote: > Am Mi., 31. Jan. 2024 um 11:15 Uhr schrieb Marek Kasik >: > > > > Hi, > > > > On 1/30/24 12:15, Michael J Gruber wrote: > > > Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34: > > >> Hi, > > >> > > >> I plan to rebase poppler to 24.02.0 once it is released. It will be > > >> probably released this week and I would like to get it to rawhide > before > > >> the branching together with rebuilds of dependent packages. > > >> > > >> I'll prepare the build in a side tag and will message relevant > > >> maintainers to rebuild their packages there. > > >> > > >> The packages which will need rebuilds: > > >>calligra > > >>gambas3 > > >>gdal > > >>gdcm > > >>inkscape > > >>kf5-kitinerary > > >>libreoffice > > >>pdf2djvu > > >>scribus > > > > > > That list is surprisingly short. For example, poppler-glib requires a > > > specific poppler version, and via poppler-glib-devel that affects more > > > packages (zathura-pdf-poppler comes to my mind). > > > > > > Does libpoppler-glib stay at the same soname and "absorb" all poppler > > > changes behind its ABI? > > > > yes, libpoppler-glib and other front-ends are stable so they'll stay on > > their sonames. The soname which is going to be changed is soname of the > > core library which is not stable. The packages mentioned above uses the > > core library directly so we have to keep the unstable API available. > > Thanks, that clarifies everything. > > Cheers > Michael > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
[rpms/perl-Wx] PR #3: Remove unneeded complexity of the gtk requires hack
spot merged a pull-request against the project: `perl-Wx` that you are following. Merged pull-request: `` Remove unneeded complexity of the gtk requires hack `` https://src.fedoraproject.org/rpms/perl-Wx/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
New packages needed to update cura
Hi friends, There are two new packages that need to be added to Fedora in order to update Cura: * asio-grpc - https://bugzilla.redhat.com/show_bug.cgi?id=2255630 * CuraEngine_grpc_definitions - https://bugzilla.redhat.com/show_bug.cgi?id=2255633 These should be very easy reviews, asio-grpc is a noarch header only package, and CuraEngine_grpc_definitions is just a lot of protobuf files that get compiled into a single library. Will trade reviews if needed. Thanks in advance, ~spot -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[rpms/perl-MARC-Record] PR #1: Package tests and format license to SPDX
spot merged a pull-request against the project: `perl-MARC-Record` that you are following. Merged pull-request: `` Package tests and format license to SPDX `` https://src.fedoraproject.org/rpms/perl-MARC-Record/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Devel-Cover] PR #1: Add dependency to Perl version on which was build
spot merged a pull-request against the project: `perl-Devel-Cover` that you are following. Merged pull-request: `` Add dependency to Perl version on which was build `` https://src.fedoraproject.org/rpms/perl-Devel-Cover/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Image-ExifTool] PR #1: Update to 12.69
spot closed without merging a pull-request against the project: `perl-Image-ExifTool` that you are following. Closed pull-request: `` Update to 12.69 `` https://src.fedoraproject.org/rpms/perl-Image-ExifTool/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Image-ExifTool] PR #1: Update to 12.69
spot commented on the pull-request: `Update to 12.69` that you are following: `` Upstream for this one has asked us to track latest stable in CPAN, not latest available. Also, I am not a fan of %autorelease/%autochangelog. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Image-ExifTool/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Net-SNMP] PR #1: Remove deprecated Socket6 library
spot merged a pull-request against the project: `perl-Net-SNMP` that you are following. Merged pull-request: `` Remove deprecated Socket6 library `` https://src.fedoraproject.org/rpms/perl-Net-SNMP/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-SNMP_Session] PR #2: Fix IPv6 functionality of SNMP_Session
spot merged a pull-request against the project: `perl-SNMP_Session` that you are following. Merged pull-request: `` Fix IPv6 functionality of SNMP_Session `` https://src.fedoraproject.org/rpms/perl-SNMP_Session/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Tie-IxHash] PR #1: Update license to SPDX format
spot merged a pull-request against the project: `perl-Tie-IxHash` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Tie-IxHash/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Mail-Sender] PR #1: Update license to SPDX format
spot merged a pull-request against the project: `perl-Mail-Sender` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Mail-Sender/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-HTML-Tree] PR #1: Update license to SPDX format
spot merged a pull-request against the project: `perl-HTML-Tree` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-HTML-Tree/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-File-Which] PR #1: Update license to SPDX format
spot merged a pull-request against the project: `perl-File-Which` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-File-Which/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-File-HomeDir] PR #1: Update license to SPDX format
spot merged a pull-request against the project: `perl-File-HomeDir` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-File-HomeDir/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-PPI-Tester] PR #1: Update Makefile.PL to not use Module::Install::DSL
spot merged a pull-request against the project: `perl-PPI-Tester` that you are following. Merged pull-request: `` Update Makefile.PL to not use Module::Install::DSL `` https://src.fedoraproject.org/rpms/perl-PPI-Tester/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-SNMP_Session] PR #1: Fix ipv6
spot merged a pull-request against the project: `perl-SNMP_Session` that you are following. Merged pull-request: `` Fix ipv6 `` https://src.fedoraproject.org/rpms/perl-SNMP_Session/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
TeXLive 2023
Hi Fedora, TeXLive 2023 (composed of texlive-base and texlive SRPMs) is in rawhide now. I've done local testing to try to make sure it doesn't break anything obvious... but the size and scope of TL means that there are probably still some bugs introduced by this update. Change wiki page here: https://fedoraproject.org/wiki/Changes/TeXLive2023 Please let me know if something stops building as a result of the new texlive packages, either via email, bugzilla, twitter, mastodon, or carrier pigeon, with as much detail as you can provide. There is at least one clear bug: texlive-texaccents (from texlive-base) will not install at the moment, because it depends on snobol4. Snobol4 is not in Fedora yet, I have made a new package which is pending review (and it shouldn't be a hard review), so help with reviewing would be appreciated: https://bugzilla.redhat.com/show_bug.cgi?id=2182080 Note that texlive-texaccents used to be Python, but upstream decided to rewrite it in SNOBOL. The only thing (I think) that depends on texaccents is texlive-collection-binextra. I do not plan to push TeXLive 2023 to any stable Fedora, just let it get inherited for Fedora 39+. Also, this is the fastest I've ever turned around a TeXLive build (mostly because I had just updated most things for 2022 in January). ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[rpms/perl-Wx] PR #2: Rebuild with wxWidgets 3.2
spot commented on the pull-request: `Rebuild with wxWidgets 3.2` that you are following: `` Ah, I see my mistake, I was looking at wxGTK3. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Wx/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Wx] PR #2: Rebuild with wxWidgets 3.2
spot closed without merging a pull-request against the project: `perl-Wx` that you are following. Closed pull-request: `` Rebuild with wxWidgets 3.2 `` https://src.fedoraproject.org/rpms/perl-Wx/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Wx] PR #2: Rebuild with wxWidgets 3.2
spot commented on the pull-request: `Rebuild with wxWidgets 3.2` that you are following: `` I manually applied this, since it went out of sync with the mass rebuild. I did notice that wxWidgets 3.2 doesn't seem to be in rawhide yet, you might want to make sure you get that in there quickly or this will start failing to build. :) `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Wx/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Alien-wxWidgets] PR #2: Rebuild with wxWidgets 3.2
spot merged a pull-request against the project: `perl-Alien-wxWidgets` that you are following. Merged pull-request: `` Rebuild with wxWidgets 3.2 `` https://src.fedoraproject.org/rpms/perl-Alien-wxWidgets/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TeXLive 2022 landing in rawhide today
Please open a bug on this so I can track it. Thanks, ~spot On Sat, Jan 7, 2023 at 11:11 AM Orion Poplawski wrote: > On 1/4/23 17:52, Tom Callaway wrote: > > Hi Fedora, > > > > TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in > > rawhide today. I've done extensive local testing in mock to try to make > > sure it doesn't break anything obvious... but the size and scope of TL > > means that there are probably still some bugs introduced by this update. > > > > Please let me know if something stops building as a result of the new > > texlive packages, either via email, bugzilla, twitter, mastodon, or > > carrier pigeon, with as much detail as you can provide. > > > > I do not plan to push this to any stable Fedora, BUT, I have tested with > > it installed over Fedora 37 and it seems to work okay for me. > > > > Apologies on the delay in getting this done. I realize TL 2023 is > > probably coming out in a few months, hopefully, it will not take a year > > for me to get that update in place. > > > > ~spot > > Seems to be breaking LaTeXML's tests: > https://apps.fedoraproject.org/koschei/package/LaTeXML?collection=f38 > > Unfortunately koschei's query to see what else might be affected hits a > gateway timeout: > > > https://koschei.fedoraproject.org/affected-by/texlive-latex?epoch1=9=20210325=52.fc38=10=svn63825=55.fc38=f38 > > Would be nice if that could be given more time to complete. > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > IT Systems Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > 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: TeXLive 2022 landing in rawhide today
Despite the size, I don't think TL updates have ever gone through that process before. Not opposed to doing it though, do we need to revert those builds from rawhide? ~spot On Wed, Jan 4, 2023 at 10:26 PM Peter Robinson wrote: > Hi Spot, > > > TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in > rawhide today. I've done extensive local testing in mock to try to make > sure it doesn't break anything obvious... but the size and scope of TL > means that there are probably still some bugs introduced by this update. > > > > Please let me know if something stops building as a result of the new > texlive packages, either via email, bugzilla, twitter, mastodon, or carrier > pigeon, with as much detail as you can provide. > > > > I do not plan to push this to any stable Fedora, BUT, I have tested with > it installed over Fedora 37 and it seems to work okay for me. > > > > Apologies on the delay in getting this done. I realize TL 2023 is > probably coming out in a few months, hopefully, it will not take a year for > me to get that update in place. > > While I appreciate the work here and I trust you to get it right I > can't help but think a change of this size should be going through the > official change process and I don't see an approved change for F-38 > [1], is there a reason not to go via this process? > > Peter > > [1] > https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=gnupg2=Fedora=Fedora%20EPEL > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
TeXLive 2022 landing in rawhide today
Hi Fedora, TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in rawhide today. I've done extensive local testing in mock to try to make sure it doesn't break anything obvious... but the size and scope of TL means that there are probably still some bugs introduced by this update. Please let me know if something stops building as a result of the new texlive packages, either via email, bugzilla, twitter, mastodon, or carrier pigeon, with as much detail as you can provide. I do not plan to push this to any stable Fedora, BUT, I have tested with it installed over Fedora 37 and it seems to work okay for me. Apologies on the delay in getting this done. I realize TL 2023 is probably coming out in a few months, hopefully, it will not take a year for me to get that update in place. ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[rpms/perl-DBD-SQLite] PR #2: Tests
spot merged a pull-request against the project: `perl-DBD-SQLite` that you are following. Merged pull-request: `` Tests `` https://src.fedoraproject.org/rpms/perl-DBD-SQLite/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Chromium security bugs remain unfixed for > 1 month
Apologies for the delays. My wife has been rather ill for a while, so my open source time has been greatly minimized lately. Fedora cannot use the default tarball due to legal restrictions. Additionally, Fedora uses GCC (intentionally) which requires patch work for each release, but improves the quality of the resulting package. Chromium was also breaking koji due to the large amount of memory it needs to build exceeding the available memory in VMs. The helpful Fedora Infra team has created a baremetal group for Chromium to work around this. Finally, I had been working on trying to resolve the build failures with Fedora 36, but they should now be fixed (as of last night). Of course, Google released a new major version this morning, so the terrifying carousel spins anew. Your patience is appreciated. ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
libvpx soname bump 6.3.0 -> 7.0.0
Updating libvpx in rawhide to 1.11.0 comes with an soname bump to 7.0.0. Affected Fedora packages: * baresip * godot * gstreamer1-plugins-good * linphone * qt5-qtwebengine * seamonkey * toxcore * utox * xpra I'm doing a rawhide chain-build since all of these rebuild locally without issue against the new libvpx. Hopefully that will go fine, but we'll see. ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Bumping lapack to 3.10.0 in rawhide
LAPACK & BLAS are going to 3.10.0 in rawhide. The sover on the shared libs is still at .3, so it _should_ not break anything, but there is a history of this not always being true. Please file bugs if things stop building against LAPACK/BLAS. Thanks, ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RPMLint 2.0 released!
I have landed rpmlint 2.0.0 in rawhide, along with Mirek Suchý's toml configs (with updates for the licenses.toml). PRs, bug reports, and suggestions welcome. Thanks, ~spot On Wed, May 19, 2021 at 6:55 AM Miroslav Suchý wrote: > Dne 19. 05. 21 v 6:46 Michal Schorm napsal(a): > > * RPMLint includes _many more checks_! Nearly all of the generally > > However I always have a hard time understanding what the issue caught > by RPMLint actually is. > I would like to see some library of the checks with the explanation of > what it is, why it is important and usual examples of bad / correct > code and how to fix it. Something like CWEs (e.g. [1]) > Is there something like it already by any chance ? > > There is a long way between an error / warning being reported by > RPMLint with maintainer just ignoring it, and the maintainer to > understand the value and importance of having it fixed (as well as > knowledge how to fix it) > > [1] https://cwe.mitre.org/data/definitions/416.html > > $ python3 lint.py /tmp/tito/rpmconf-1.1.4-1.fc34.src.rpm > > ... > > rpmconf.src: E: description-line-too-long This tool search ... > > $ python3 lint.py -e description-line-too-long > description-line-too-long: > Your description lines must not exceed 79 characters. If a line is > exceeding > this number, cut it to fit in two lines > > Or you can run rpmlint in verbose mode "-v" where this explanation is > printed for every findings. > > > Is this good enough? ;) > > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: texlive 2021 landing in Rawhide
I have new builds of texlive (2021-41.fc35) and texlive-base (20210325-34.fc35) going. Fixes: - add texlive-gsftopk as a dependency on texlive-texlive-scripts for mktexpk - add texlive-psnfss as a dependency on texlive-latex - drop Requires: tex(psfonts.map), died with updmap-map - add tfm font provides to texlive-cm - add beamerthemenord component package to resolve broken deps - add latex-firstaid-dev component package to resolve broken deps - fix typo in Requires for texlive-pst-optexp - fix deps for texlive-kvmap Assuming those build (and they should, fingers crossed), I am cautiously optimistic that the reported build failures will go away. If they do not, you know what to do (either reply here, file new bugs, or add new info to the existing ones). Thanks for your help, ~spot On Thu, May 27, 2021 at 8:43 PM Miro Hrončok wrote: > On 27. 05. 21 23:17, Tom Callaway wrote: > > Hi Fedorans, > > > > Just a heads-up, texlive-base (where the compiled code and immediate > > dependencies lives) and texlive (where the thousands of other noarch > components > > live) have been updated to TeXLive 2021 in Rawhide (and the latest > available > > components from CTAN at the time I did the work). > > > > I've done local testing and everything seems to still work, but > inevitably, the > > act of updating TeXLive breaks things, so if your packages have TeX > > dependencies and stop building in rawhide, let me know. > > Hey Spot, thanks for the update. > > I see some problems in Koschei, I've reported them in > https://bugzilla.redhat.com/show_bug.cgi?id=1965547 > > Inlining the problems here as well in case you prefer to discuss them via > email: > > > https://koschei.fedoraproject.org/package/python-mplcairo?collection=f35 > https://koschei.fedoraproject.org/package/python-matplotlib?collection=f35 > > No package found for: tex(cmsy10.tfm) > No package found for: tex(cmmi10.tfm) > No package found for: tex(cmb10.tfm) > No package found for: tex(cmex10.tfm) > No package found for: tex(cmss10.tfm) > > > > > > https://koschei.fedoraproject.org/package/python-nbconvert?collection=f35 > > Problem: package texlive-scheme-full-9:svn54074-40.fc35.noarch > requires > texlive-collection-latexextra, but none of the providers can be installed > - conflicting requests > - nothing provides texlive-beamerthemenord needed by > texlive-collection-latexextra-9:svn59009-40.fc35.noarch > > > > > > https://koschei.fedoraproject.org/package/python-sphinx?collection=f35 > > This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021) (preloaded > format=pdflatex) > restricted \write18 enabled. > entering extended mode > (pdflatex/python.tex > LaTeX2e <2020-10-01> patch level 4 > L3 programming layer <2021-05-07> (./sphinxmanual.cls > Document Class: sphinxmanual 2019/12/01 v2.3.0 Document class (Sphinx > manual) > (/usr/share/texlive/texmf-dist/tex/latex/base/report.cls > Document Class: report 2020/04/10 v1.4m Standard LaTeX document class > (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))) > (/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty) > (/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty) > (/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty<>) > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty > For additional information on amsmath, use the `?' option. > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty)) > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty) > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty)) > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty)) > (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty > (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def > (/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def)) > (/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf)) > (/usr/share/texlive/texmf-dist/tex/latex/psnfss/times.sty) > (/usr/share/texlive/texmf-dist/tex/latex/fncychap/fncychap.sty) > (./sphinx.sty > (/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty) > (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty > (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty) > (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty > (/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty) > (/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg) > (/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def))) > (/usr/share/texlive/texmf-dist/tex/latex/f
texlive 2021 landing in Rawhide
Hi Fedorans, Just a heads-up, texlive-base (where the compiled code and immediate dependencies lives) and texlive (where the thousands of other noarch components live) have been updated to TeXLive 2021 in Rawhide (and the latest available components from CTAN at the time I did the work). I've done local testing and everything seems to still work, but inevitably, the act of updating TeXLive breaks things, so if your packages have TeX dependencies and stop building in rawhide, let me know. Also, FWIW, I have no plans to bring this back to any stable branches. TL2020 is doing well enough there for now. Thanks in advance for your patience, ~spot P.S. Please don't start the "WHY THE #$%& does texlive make so many subpackages" thread unless you're sending me money, fine alcohol, or patches. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Let's retire original glib and gtk+
FWIW, I have retired xmms. Upstream is long gone, and it was being held together by spider-webs anyways. ~spot On Wed, May 26, 2021 at 4:43 AM Peter Robinson wrote: > On Tue, May 25, 2021 at 11:01 PM Michael Catanzaro > wrote: > > > > On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple > > wrote: > > > I have no idea how significant this might be, but perhaps this should > > > be discussed more publicly. > > > > Use containers? Ship your own glib as a static lib? I'm impressed you > > have software that still needs it tbh. > > I think copr is the perfect place for these sort of things for those > that care enough. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
New lapack packages in rawhide
Hi Fedorans,
I've updated lapack to 3.9.1 in rawhide. This comes with several notable
changes:
1. I've moved to using the upstream build files, specifically, cmake. This
eliminates lots of ancient cruft in the Fedora lapack package that needed
to be redone by hand with every new release.
2. This change means that the lapack and cblas header files are installed
where upstream intends them to be installed, which is under /usr/include,
rather than /usr/include/{lapack,cblas}/. You may need to adjust your
dependent packages for this, but as this is the upstream behavior, you may
have had to patch your package to find the files (and now you should not
need to).
3. That said, there are now cmake helpers along with the pkgconfig files.
If your package detects either of these and uses them during build to set
includepaths, you should not need to change anything.
4. There is now a libtmglib shared library in lapack. Previously, these
symbols lived inside liblapacke (which is still present, just now linked to
libtmglib for those symbols).
5. I have disabled debuginfo. Lapack has a special "64_" variant where the
library symbols are prefixed with "64_", but the debuginfo process was
undoing this (somehow). This has been true for a while, which makes me
wonder how many people were actually using that variant, but whatever.
Given the scope of this change, I do not plan to push it to Fedora 34 or
older at this time. If you find any bugs, please let me know through any of
the usual channels (bugzilla, email, etc).
~spot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[rpms/perl-Font-AFM] PR #3: use NimbusSans-Bold font in test instead of phvr
spot merged a pull-request against the project: `perl-Font-AFM` that you are following. Merged pull-request: `` use NimbusSans-Bold font in test instead of phvr `` https://src.fedoraproject.org/rpms/perl-Font-AFM/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Orphaning the cura-lulzbot package set
This fork of cura has basically been abandoned by upstream, and the new company that acquired Lulzbot has gone out of compliance with the source code for the firmware. They have made it very clear that they have no real interest in working with the community to improve this situation, and I no longer have any motivation to maintain these packages. Accordingly, I've orphaned the following packages: * cura-lulzbot * lulzbot-marlin-firmware * CuraEngine-lulzbot * python-uranium-lulzbot ~spot P.S. I opened an upstream pull request to add support for the Lulzbot TAZ Pro and the Mini 2 in the main Cura codebase (still actively maintained). I would highly recommend that anyone considering reviving these packages devote their efforts in that direction instead. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Bullet update (sover bump)
Hi Fedorans, With the consent of the maintainer, I updated bullet to 3.08 in Fedora 34 and Rawhide. I also am in the process of rebuilding the dependent packages in Fedora (they all work fine for me in local rebuilds). gazebo and fawkes are still going, but the others are done. There is also one dependent package in rpmfusion that will need to be rebuilt (openmw). If you see anything obviously broken, please poke me. Thanks, ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-HTML-Format] PR #1: Correct dependencies
spot merged a pull-request against the project: `perl-HTML-Format` that you are following. Merged pull-request: `` Correct dependencies `` https://src.fedoraproject.org/rpms/perl-HTML-Format/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: List of long term FTBFS packages to be retired in February
Looks like VirtualGL was rebuilt: https://koji.fedoraproject.org/koji/packageinfo?packageID=14293 ~spot On Mon, Dec 28, 2020 at 3:57 PM Miro Hrončok wrote: > Dear maintainers. > > Based on the current fail to build from source policy, the following > packages > will be retired from Fedora 34 approximately one week before branching > (February > 2021). > > Policy: > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > Note that some listed packages are orphaned and hence may be retired even > sooner. > > The packages in rawhide were not successfully built at least since Fedora > 32. > > This report is based on dist tags. > > Packages collected via: > > https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb > > If you see a package that was built, please let me know. > If you see a package that should be exempted from the process, please let > me > know and we can work together to get a FESCo approval for that. > > If you see a package that can be rebuilt, please do so. > >Package (co)maintainers > Latest build > > === > VirtualGL gsgatlin Fedora > 31 > boo elsupergomez, orphan, tpokorra Fedora > 31 > gmpcorphan Fedora > 31 > jboss-servlet-2.5-api dmoluguw, orphan Fedora > 31 > js-html5shivorphan Fedora > 31 > js-respond orphan Fedora > 31 > nodejs-info-symbol orphan Fedora > 31 > nodejs-interpretnodejs-sig, orphan Fedora > 31 > nodejs-net-browserify-alt orphan Fedora > 31 > nodejs-win-spawnnodejs-sig, orphan Fedora > 31 > rubygem-net-ssh-multi maxamillion, orphan, tdawson Fedora > 31 > sugar-flipstickscallkalpa, chimosky, pbrobinson, Fedora > 31 > tuxbrewr > sugar-getiabookscallkalpa, chimosky, pbrobinson, Fedora > 31 > tuxbrewr > sugar-infoslicercallkalpa, chimosky, pbrobinson, Fedora > 31 > tuxbrewr > sugar-labyrinth callkalpa, chimosky, pbrobinsonFedora > 31 > sugar-ruler callkalpa, chimoskyFedora > 31 > sugar-starchart callkalpa, chimosky, orphanFedora > 31 > sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora > 31 > tuxbrewr > sugar-visualmatch chimosky, orphan Fedora > 31 > sugar-yupanacallkalpa, chimosky, orphanFedora > 31 > > > The following packages require above mentioned packages: > > Depending on: js-html5shiv (1) > copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, > msuchy, praiskup) > copr-frontend-1.171-1.fc34.noarch requires js-html5shiv > > Depending on: nodejs-info-symbol (2) > nodejs-log-utils (maintained by: orphan) > nodejs-log-utils-0.2.1-6.fc32.noarch requires > npm(info-symbol) > > nodejs-time-diff (maintained by: orphan) > nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol) > > Depending on: nodejs-interpret (1) > nodejs-shelljs (maintained by: fab, nodejs-sig, patches) > nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret) > > > Affected (co)maintainers (directly and indirectly): > callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks, > sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks > chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks, > sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart, > sugar-getiabooks > clime: js-html5shiv > copr-sig: js-html5shiv > dmoluguw: jboss-servlet-2.5-api > dturecek: js-html5shiv > elsupergomez: boo > fab: nodejs-interpret > frostyx: js-html5shiv > gsgatlin: VirtualGL > maxamillion: rubygem-net-ssh-multi > msuchy: js-html5shiv > nodejs-sig: nodejs-win-spawn, nodejs-interpret > patches: nodejs-interpret > pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides, > sugar-infoslicer, sugar-getiabooks > praiskup: js-html5shiv > tdawson: rubygem-net-ssh-multi > tpokorra: boo > tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks, > sugar-flipsticks > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: >
Re: Chromium built in rawhide does not render most strings
https://bugs.chromium.org/p/chromium/issues/detail?id=1164975 Please add in this info, it was on my TODO list, but clearly hasn't happened yet. ~spot On Wed, Jan 13, 2021 at 8:33 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Wednesday, 13 January 2021 at 03:14, Kevin Kofler via devel wrote: > > Florian Weimer wrote: > > > Right, and the glibc 2.33 versions all call fstatat64 in the end > (system > > > call number 0x106). > > > > That would be: > > > > #if !defined(__NR_newfstatat) > > #define __NR_newfstatat 262 > > #endif > > > > from: > > > > > https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/system_headers/x86_64_linux_syscalls.h > > > > > The older x versions call the earlier system calls > > > (numbers 4, 5, 6) > > > > And these are defined as: > > > > #if !defined(__NR_stat) > > #define __NR_stat 4 > > #endif > > > > #if !defined(__NR_fstat) > > #define __NR_fstat 5 > > #endif > > > > #if !defined(__NR_lstat) > > #define __NR_lstat 6 > > #endif > > > > I see that the sandbox is treating __NR_newfstatat as IsFileSystem, like > > __NR_stat and __NR_lstat, whereas __NR_fstat is under > > IsAllowedFileSystemAccessViaFd. So the issue is that everything now > calls > > the same syscall under the hood, so the sandbox can no longer > distinguish > > the two access types just by looking at the syscall ID. > > > > The baseline policy disallows everything under IsFileSystem and allows > only > > IsAllowedFileSystemAccessViaFd: > > > https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc > > (i.e., __NR_fstat is allowed, whereas __NR_stat, __NR_lstat, and > > __NR_newfstatat are not). > > I think you wanted to link > > https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc > here instead. > __NR_newfstatat is at line 116 and __NR_fstat is at line 170. Note that > plain __NR_stat and __NR_lstat are also rejected (lines 101 and 94). > > > It looks like it needs to restrict the arguments to __NR_newfstatat (to > an > > empty path and the AT_EMPTYPATH flag) instead of rejecting it outright, > so > > that fstat keeps working, see: > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fstat.c;h=dc117361ffe7064be7c6746465388803e203adcf;hb=HEAD > > Is there an upstream bug open for this already? > > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Based on my (admittedly extremely limited) understanding of things, this seems correct as is: #if defined(__x86_64__) || defined(__aarch64__) case __NR_newfstatat: // fstatat(). EPERM not a valid errno. #elif defined(__i386__) || defined(__arm__) || \ (defined(ARCH_CPU_MIPS_FAMILY) && defined(ARCH_CPU_32_BITS)) case __NR_fstatat64: #endif Is fstatat64 actually implemented on x86_64 now? Alternately, if you'd prefer to simply open an upstream bug with Google, just let me know. :) I want to be helpful here, but not waste your time. Thanks, ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Looks like this might be it. Running with --no-sandbox brings back the strings. Is there a reference to how the stat calls should now be done? Thanks, ~spot On Fri, Jan 8, 2021 at 8:58 AM Florian Weimer wrote: > * Tom Callaway: > > > This makes me very suspicious of something in glibc between 2.32 > > (Fedora 33) and 2.32.9000 (rawhide), but I'm not sure where to look > > from here. Any ideas? > > Does the issue go away if you disable the Chromium sandbox? > > One difference is that the stat functions are called in a different way, > and perhaps the sandbox isn't ready for that. > > Thanks, > Florian > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Okay, to try to narrow this down a bit, I setup a very large AWS Fedora 33 instance and built chromium packages, then installed them into a second Fedora Rawhide instance. As before, these packages work fine. (This is our baseline) Next, I updated glibc (and JUST glibc, glibc-common, glibc-devel, glibc-headers, glibc-langpack-en) from Rawhide on the Fedora 33 instance and built the chromium package again. This build, when installed into Fedora Rawhide, exhibits the text rendering issue. This makes me very suspicious of something in glibc between 2.32 (Fedora 33) and 2.32.9000 (rawhide), but I'm not sure where to look from here. Any ideas? ~spot On Sun, Jan 3, 2021 at 4:49 AM Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 02/01/21 22:57, Kevin Kofler via devel ha scritto: > > Tom Callaway wrote: > >> I rebuilt chromium, but it did not resolve the issue. > > So what can we do to resolve the issue? Surely we cannot leave both > Chromium > > and Falkon unable to render text forever. > > > > Kevin Kofler > > ___ > > The problem seems to be qt5-qtwebengine is unable to use system fonts. > It doesn't render text using default fonts (i.e. 'serif' or 'sans-serif' > css styles), but it does render text using custom css fonts. In fact, it > renders most of qt.io homepage (using 'Titillium Web' custom css font) > and also some text on Bodhi homepage (using 'Open Sans' custom css font). > > However, opening, for example, Falkon settings, I can get the fonts > under the Character settings and the preview works. > > Mattia > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
I rebuilt chromium, but it did not resolve the issue. ~spot On Wed, Dec 30, 2020 at 5:35 PM Marius Schwarz wrote: > Am 30.12.20 um 14:07 schrieb Mattia Verga via devel: > > Il 30/12/20 10:14, Marius Schwarz ha scritto: > >> Don't you need to recompile stuff first to have an effect? :) > >> > >> > > I've just pushed a rebuild for qt5-qtwebengine, let's see if that's > enough. > > > > I had a chromium 85 build running instead of the 87er, that had no > problems rendering texts. My guerss is, that chromium needs a rebuild too. > > Best regards, > Marius > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
I downgraded cairo to 1.16.0-9.fc33 and it had no effect, the bug remained. Thanks, ~spot On Thu, Dec 17, 2020 at 11:19 AM Kalev Lember wrote: > On Thu, Dec 17, 2020 at 5:12 PM Tom Callaway wrote: > >> Okay, this one has me stumped. Any chromium package I build through >> rawhide refuses to render most of the strings. >> >> At first, I thought this was gcc 11, but then I noticed that the first >> build with this problem was built before GCC 11 landed in rawhide (the >> compiler was the same n-v-r as the one in Fedora 33). Next, I thought it >> must be due to a newer system component that Chromium uses dynamically, but >> I was able to disprove that by installing the Fedora 33 build (same >> version-release) into a Rawhide VM, and it works fine. Google Chrome also >> works fine in rawhide. >> >> It seems that this must be something that is contained within chromium, >> that when built in rawhide, builds broken. >> >> Here's a screenshot of what it looks like: >> https://twitter.com/spotfoss/status/1338918235719299072/photo/1 >> >> Note that some text strings are rendering (in the UI, in the "search >> box"), but most of them are not (the "HTML5Test" text below the icon, all >> of the strings in the developer console). >> > > Can you try downgrading cairo to the f33 version (1.16.0), just to rule > that out? We updated it to the 1.17.4 development version in rawhide and I > think we're the first distro to ship it, so it could possibly have issues. > > -- > Kalev > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Certainly not ruling out glibc as the problem here, but if it was glibc, I would think the problem would arise when I install the Fedora 33 build in rawhide, and it does not... ~spot On Thu, Dec 17, 2020 at 12:10 PM Robbie Harwood wrote: > Tom Callaway writes: > > > I cannot install the rawhide-built chromium into F33 without bringing > glibc > > from rawhide with me: > > > > [spot@localhost ~]$ sudo rpm -Uvh > > chromium-common-87.0.4280.88-1.fc34.x86_64.rpm > > chromium-87.0.4280.88-1.fc34.x86_64.rpm > > error: Failed dependencies: > > libc.so.6(GLIBC_2.33)(64bit) is needed by > > chromium-common-87.0.4280.88-1.fc34.x86_64 > > libc.so.6(GLIBC_2.33)(64bit) is needed by > > chromium-87.0.4280.88-1.fc34.x86_64 > > > > When I _just_ update glibc from rawhide on an otherwise Fedora 33 > instance > > (glibc, glibc-all-langpacks, glibc-common, glibc-devel, > glibc-headers-x86, > > glibc-langpack-en), then install the rawhide built chromium, it exhibits > > the same missing strings bug. > > Interesting. Seems like that points at the problem being > glibc-adjacent, no? That's still really wide though... > > Thanks, > --Robbie > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
I cannot install the rawhide-built chromium into F33 without bringing glibc
from rawhide with me:
[spot@localhost ~]$ sudo rpm -Uvh
chromium-common-87.0.4280.88-1.fc34.x86_64.rpm
chromium-87.0.4280.88-1.fc34.x86_64.rpm
error: Failed dependencies:
libc.so.6(GLIBC_2.33)(64bit) is needed by
chromium-common-87.0.4280.88-1.fc34.x86_64
libc.so.6(GLIBC_2.33)(64bit) is needed by
chromium-87.0.4280.88-1.fc34.x86_64
When I _just_ update glibc from rawhide on an otherwise Fedora 33 instance
(glibc, glibc-all-langpacks, glibc-common, glibc-devel, glibc-headers-x86,
glibc-langpack-en), then install the rawhide built chromium, it exhibits
the same missing strings bug.
~spot
On Thu, Dec 17, 2020 at 11:29 AM Robbie Harwood wrote:
> Tom Callaway writes:
>
> > Okay, this one has me stumped. Any chromium package I build through
> rawhide
> > refuses to render most of the strings.
> >
> > At first, I thought this was gcc 11, but then I noticed that the first
> > build with this problem was built before GCC 11 landed in rawhide (the
> > compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
> > must be due to a newer system component that Chromium uses dynamically,
> but
> > I was able to disprove that by installing the Fedora 33 build (same
> > version-release) into a Rawhide VM, and it works fine. Google Chrome also
> > works fine in rawhide.
> >
> > Chromium has a lot of bundled components, so it is usually fairly
> resistant
> > to system changes. There are no differences between how Chromium builds
> > (within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
> > %{optflags}, so the compiler flags are equivalent.
> >
> > Could this be due to some quirk of binutils in the way chromium gets
> linked
> > in rawhide? Is there something else unique to how packages are built in
> > rawhide right now? Are any other rawhide packages having similar string
> > issues?
>
> Have you tried the reverse? rawhide-built chromium into fc33?
>
> Thanks,
> --Robbie
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Chromium built in rawhide does not render most strings
Okay, this one has me stumped. Any chromium package I build through rawhide
refuses to render most of the strings.
At first, I thought this was gcc 11, but then I noticed that the first
build with this problem was built before GCC 11 landed in rawhide (the
compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
must be due to a newer system component that Chromium uses dynamically, but
I was able to disprove that by installing the Fedora 33 build (same
version-release) into a Rawhide VM, and it works fine. Google Chrome also
works fine in rawhide.
It seems that this must be something that is contained within chromium,
that when built in rawhide, builds broken.
Here's a screenshot of what it looks like:
https://twitter.com/spotfoss/status/1338918235719299072/photo/1
Note that some text strings are rendering (in the UI, in the "search box"),
but most of them are not (the "HTML5Test" text below the icon, all of the
strings in the developer console).
Chromium has a lot of bundled components, so it is usually fairly resistant
to system changes. There are no differences between how Chromium builds
(within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
%{optflags}, so the compiler flags are equivalent.
Could this be due to some quirk of binutils in the way chromium gets linked
in rawhide? Is there something else unique to how packages are built in
rawhide right now? Are any other rawhide packages having similar string
issues?
Here are some builds for comparison:
Fedora 34: Chromium 87.0.4280.88 (built against GCC 11):
https://koji.fedoraproject.org/koji/taskinfo?taskID=57595738
Fedora 34: Chromium 87.0.4280.88 (built against GCC 10, same as Fedora 33):
https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 33: Chromium 87.0.4280.88 (build against GCC 10, but actually works
in rawhide):
https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 34: Chromium 88.0.4324.27 (beta version of chromium, also broken)
https://koji.fedoraproject.org/koji/taskinfo?taskID=56977476
Thanks in advance,
~spot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[rpms/perl-Class-DBI] PR #1: Improve compatibility with EL8
spot merged a pull-request against the project: `perl-Class-DBI` that you are following. Merged pull-request: `` Improve compatibility with EL8 `` https://src.fedoraproject.org/rpms/perl-Class-DBI/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: chromium/ffmpeg fails on aarch64 in F33+
Filed as 1869884. ~tom On Tue, Aug 18, 2020 at 5:38 PM Jeff Law wrote: > On Tue, 2020-08-18 at 17:26 -0400, Tom Callaway wrote: > > I don't know aarch64 assembly, but chromium (or more specifically, the > ffmpeg part of chromium) is failing on aarch64 on F33+ (everywhere else it > is fine): > > > > obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function > `ff_prefetch_aarch64': > > (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against > symbol `ff_prefetch_aarch64' defined in .text section in > obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o > > > > The relevant asm is short and has not seen any change in a while, so I'm > suspicious of the toolchain. > > > > Any help is appreciated so we can get chromium security updates into > F33+. > I would guess that there's either a conditional jump to an undefined label > or to > a label that is too far away. > > Toolchain? Likely. GCC is probably the most appropriate component. > > jeff > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
chromium/ffmpeg fails on aarch64 in F33+
I don't know aarch64 assembly, but chromium (or more specifically, the ffmpeg part of chromium) is failing on aarch64 on F33+ (everywhere else it is fine): obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function `ff_prefetch_aarch64': (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol `ff_prefetch_aarch64' defined in .text section in obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o The relevant asm is short and has not seen any change in a while, so I'm suspicious of the toolchain. Any help is appreciated so we can get chromium security updates into F33+. Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Chromium failing on aarch64 in rawhide
This one is odd. Chromium is failing on aarch64 in rawhide, on a bit of ffmpeg code that has not changed in _years_. [clear_key_cdm:13/13] g++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,-O2 -Wl,--gc-sections -rdynamic -o "./libclearkeycdm.so" -Wl,-soname="libclearkeycdm.so" @"./libclearkeycdm.so.rsp" FAILED: libclearkeycdm.so g++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,-O2 -Wl,--gc-sections -rdynamic -o "./libclearkeycdm.so" -Wl,-soname="libclearkeycdm.so" @"./libclearkeycdm.so.rsp" obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function `ff_prefetch_aarch64': (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol `ff_prefetch_aarch64' defined in .text section in obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. error: Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build) Child return code was: 1 EXCEPTION: [Error()] The function it references is defined in libavcodec/aarch64/videodsp.S: function ff_prefetch_aarch64, export=1 subsw2, w2, #2 prfmpldl1strm, [x0] prfmpldl1strm, [x0, x1] add x0, x0, x1, lsl #1 b.gtX(ff_prefetch_aarch64) ret endfunc Did something change in rawhide that might be breaking this? Thanks in advance, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: module 'posix' not found when module load mpi/mpich-x86_64
Lmod needed a little patch to detect Lua 5.4 as a valid version, but it's fixed and rebuilt in rawhide now (Lmod-8.3.17-2.fc33). Thanks, Tom On Tue, Jun 30, 2020 at 6:24 PM Miro Hrončok wrote: > On 30. 06. 20 19:34, Christoph Junghans wrote: > > Adding > > BuildRequires: lua-posix > > doesn't help. > > lua-posix was rebuilt for Lua 5.4 hence it is installed into > /usr/share/lua/5.4 > > lmod searches in /usr/share/lua/5.3 > > > Any ideas? > > Does lmod need a rebuild for lua-5.3? > > Given the above I assume Lmod needs to be rebuilt and/or switched to use > Lua 5.4. > > Note that /usr/share/lmod/lmod/libexec/lmod has: > > local sys_lua_path = > > "/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/lib64/lua/5.3/?.lua;/usr/lib64/lua/5.3/?/init.lua" > > I don't if that's generated on build time or whether it will require > patching. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lua 5.4.0
All of these are now fixed, except for lua-luv and lua-event. Lua-luv needs a fixed cmake (FindLua.cmake needed patching to find Lua 5.4). I've been trying to build a new cmake in rawhide all afternoon, but s390x fails to get a buildroot established each time (not due to cmake issues). The lua-luv fixes are checked into git, I'll keep trying. lua-event seems to be broken because of broken deps unrelated to Lua 5.4: nothing provides perl(:MODULE_COMPAT_5.30.1) needed by perl-Monotone-1.1-34.fc32.x86_64, so I left it alone. Thanks, Tom On Tue, Jun 30, 2020 at 10:46 AM Miro Hrončok wrote: > On 30. 06. 20 16:06, Miro Hrončok wrote: > > > > The current status is: > > > > $ comm -23 <(repoquery --refresh --repo=koji --whatrequires 'lua(abi) = > 5.3' > > --source | pkgname | sort) <(repoquery --repo=koji --whatrequires > 'lua(abi) = > > 5.4' --source | pkgname | sort) > > > > librs232 > https://bugzilla.redhat.com/show_bug.cgi?id=1852144 > > > lua-cqueues > https://bugzilla.redhat.com/show_bug.cgi?id=1852147 > > > lua-event > https://bugzilla.redhat.com/show_bug.cgi?id=1852150 > > > lua-ldap > https://bugzilla.redhat.com/show_bug.cgi?id=1852154 > > > lua-luaossl > https://bugzilla.redhat.com/show_bug.cgi?id=1852157 > > > lua-luv > https://bugzilla.redhat.com/show_bug.cgi?id=1852158 > > > prosody > https://bugzilla.redhat.com/show_bug.cgi?id=1852234 > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lua 5.4.0
Okay. I duct taped lua-posix into a "working" state. Also did builds for
lua-argparse, lua-expat, lua-lpeg, and rpm (so that the macros say "5.4").
Any and all help is appreciated.
Tom
On Mon, Jun 29, 2020 at 4:37 PM Jerry James wrote:
> On Mon, Jun 29, 2020 at 2:34 PM Miro Hrončok wrote:
> > Not sure if that was enough to prevent broken deps:
> >
> > $ repoquery --repo=koji{,-source} --whatrequires 'lua(abi) = 5.3'
> > lua-argparse-0:0.5.0-10.fc32.noarch
> > lua-cqueues-0:20190813-3.fc32.x86_64
> > lua-cyrussasl-0:1.1.0-8.fc32.x86_64
> > lua-dbi-0:0.7.2-2.fc32.x86_64
> > lua-event-0:0.4.6-4.fc32.x86_64
> > lua-expat-0:1.3.0-18.fc32.x86_64
> > lua-filesystem-0:1.6.3-12.fc32.x86_64
> > lua-fun-0:0.1.3-12.fc32.noarch
> > lua-json-0:1.3.2-14.fc32.noarch
> > lua-ldap-0:1.1.0-15.fc32.x86_64
> > lua-librs232-0:1.0.3-10.20190917git1c29a27.fc32.x86_64
> > lua-logging-0:1.3.0-15.fc32.noarch
> > lua-lpeg-0:1.0.2-2.fc32.x86_64
> > lua-luaossl-0:20190731-2.fc32.x86_64
> > lua-luv-0:1.36.0.0-1.fc33.x86_64
> > lua-moonscript-0:0.5.0-4.fc32.noarch
> > lua-mosquitto-0:0.3-2.fc32.x86_64
> > lua-mpack-0:1.0.8-3.fc32.x86_64
> > lua-posix-0:33.3.1-16.fc32.x86_64
> > lua-psl-0:0.3-4.fc32.x86_64
> > lua-sec-0:0.9-2.fc32.x86_64
> > lua-socket-0:3.0-0.22.rc1.fc32.x86_64
> > lua-socket-compat-0:3.0-0.22.rc1.fc32.x86_64
> > lua-term-0:0.07-10.fc32.x86_64
> > lua-wsapi-0:1.6.1-11.fc32.noarch
> > lua-wsapi-0:1.6.1-11.fc32.src
> > luadoc-0:3.0.1-22.fc32.noarch
> > luarocks-0:3.3.1-1.fc33.x86_64
> > prosody-0:0.11.5-1.fc33.x86_64
> > rrdtool-lua-0:1.7.2-10.fc33.x86_64
> > vicious-0:2.4.1-1.fc33.noarch
>
> And since copy-jdk-configs Requires lua-posix, Java package builds are
> currently failing.
> --
> Jerry James
> http://www.jamezone.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
Lua 5.4.0
I just built lua 5.4.0 in Rawhide. As with previous major updates of lua, the package also includes a copy of the lua 5.3 libraries so that rawhide does not just become broken reps. If you depend on lua, please rebuild your packages in rawhide and let me know if you run into any issues. Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unretire: R-AnnotationDbi
Hello Fedorans, It is my intent to revive R-AnnotationDbi, as it is needed to update R-biomaRt. I've already done the review request here: https://bugzilla.redhat.com/show_bug.cgi?id=1845360 Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
There are some new subpackages (and some old ones went away), but since every package had the release value bumped, this is expected. Tom On 2020-05-27 at 00:52, ke...@scrye.com wrote: > On Tue, May 26, 2020 at 05:05:32PM -0700, Adam Williamson wrote: > ...snip... > > > there is, IIRC, supposed to be a 'spin review' process we go through > > every release which should be run by the spin wrangler and that is > > where max size changes are supposed to be done, but I don't think we've > > had a spin wrangler or actually done that process for several releases. > > So in lieu of that, I've just been telling people the above. > > https://fedoraproject.org/wiki/Spins_Wrangler > > That process is long gone and dead. The only process we have now is if > you want to add a new lab/spin you just use the Change process. > > I attempted to setup a process that required each spin to have a test at > beta and final or be dropped, but it was added after beta that cycle, so > we didn't do it then, and the next cycle a number of spins/labs failed > to compose at beta for reasons beyond the owners control, so it sort of > just got dropped. ;( > > We may want to revisit this, or at least drop any lab/spin that doesn't > have a listed 'owner' (since we now have that in file). > > kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
Perhaps graphite2 generates a .tex file as part of the process? I'd have to look at it to figure it out. Can you please open a bug on the 300+ package increase with the specifics so I can figure out what (if anything) I can do to remedy this? Thanks, Tom On Fri, May 22, 2020 at 12:16 PM José Abílio Matos wrote: > On Friday, 22 May 2020 12.51.26 WEST Fabio Valentini wrote: > > > Also, the build now fails with "! LaTeX Error: File `hanging.sty' not > > > found.". graphite2 sources do not contain any .tex files, but > > > graphite2 uses LaTeX / pdf output when building documentation / manual > > > with doxygen, so I'm pretty sure the transitive dependency on > > > `tex(hanging)` is missing somewhere else? > > > > FWIW the last part should be `tex(hanging.sty)`. And probably you are > right about the transitive dependency of this BuildRequires. :-) > > -- > > José Abílio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
If your package has a tex file that it uses to generate documentation, and
that tex file says \usepackage{foo}, then your package needs to have:
BuildRequires: tex(foo.sty)
The only exception to that is for packages which include .sty files,
obviously, if the \usepackage dependency is met within the package you
don't need to specify a Requires.
hth,
Tom
On Thu, May 21, 2020 at 7:24 AM Lumir Balhar wrote:
> Hello.
>
> I am trying to investigate a new problem in ipython that is probably
> related to the update of texlive:
> https://bugzilla.redhat.com/show_bug.cgi?id=1838474
>
> ipython uses latex to generate png images of tex formulas. Internally it
> calls latex and dvipng commands.
>
> Right now, I have a tex file:
>
> # cat /tmp/tmp93xe5ss2/tmp.tex
>
> \documentclass{article}\usepackage{amsmath}\usepackage{amsthm}\usepackage{amssymb}\usepackage{bm}\pagestyle{empty}\begin{document}$x^2$\end{document}
>
> and following command:
>
> # latex -halt-on-error -interaction batchmode /tmp/tmp93xe5ss2/tmp.tex
>
> which exits with exit code 1 and the following output:
>
> This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) (preloaded
> format=latex)
> restricted \write18 enabled.
> entering extended mode
>
> The error seems to be caused by latex missing file
> /usr/share/texlive/texmf-dist/tex/latex/amscls/amsthm.sty. When I manually
> install texlive-amscls which provides this file, everything is fine and the
> command mentioned above works.
>
> The strange thing is that when I install python3-matplotlib from koji repo
> or from rawhide repo, both don't bring this package so it's probably a new
> dependency somewhere.
>
> Do you know what might cause this?
>
> Lumír
> On 5/14/20 11:55 PM, Tom Callaway wrote:
>
> I've just kicked off new builds for texlive and texlive-base for TeXLive
> 2020 in rawhide. Hopefully, everything that depends on them will continue
> to work, but if you notice any new issues generating docs (or any missing
> components or broken dependencies), feel free to email me or open Bugzilla
> tickets.
>
> Thanks,
> Tom
>
> P.S. I have no plans to push this update to any stable branches, but if
> you really want the TL2020 magic, I'm running the F33 packages on my F32
> system without 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
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
I think the issue here is that the most recent texlive package fixes landed this morning, and the "rawhide" compose that mock would pull in doesn't have all the fixes yet. Tom On Wed, May 20, 2020 at 3:12 PM Richard Shaw wrote: > On Wed, May 20, 2020 at 2:08 PM Tom Callaway wrote: > >> I'm not sure what your failure looked like (maybe the rawhide packages >> used are older than the ones currently in the koji buildroot), but a koji >> scratch build from master succeeded without issue: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=44738672 >> > > Interesting, I know sometimes mock produces different results from Koji > but I wouldn't expect it in this case. I did both with and without > --enablerepo=local and tried again after a --scrub=all, with the same > result. > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
I'm not sure what your failure looked like (maybe the rawhide packages used are older than the ones currently in the koji buildroot), but a koji scratch build from master succeeded without issue: https://koji.fedoraproject.org/koji/taskinfo?taskID=44738672 Tom On Wed, May 20, 2020 at 2:21 PM Tom Callaway wrote: > It's probably not the same bug, that error is a fairly generic error > meaning "something has made texlive unhappy". I'm investigating. > > Tom > > On Wed, May 20, 2020 at 1:29 PM Richard Shaw wrote: > >> Thanks for the PR but it looks like I'm being bitten by: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=578426 >> >> In the mock build, so how do I generate pdflatex.fmt within a mock chroot? >> >> Thanks, >> Richard >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
It's probably not the same bug, that error is a fairly generic error meaning "something has made texlive unhappy". I'm investigating. Tom On Wed, May 20, 2020 at 1:29 PM Richard Shaw wrote: > Thanks for the PR but it looks like I'm being bitten by: > > https://bugzilla.redhat.com/show_bug.cgi?id=578426 > > In the mock build, so how do I generate pdflatex.fmt within a mock chroot? > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
Richard,
I've got a PR for you that adds your explicit tex BuildRequires so that
this works again:
https://src.fedoraproject.org/rpms/OpenColorIO/pull-request/1
Upstream TeXLive sometimes moves .sty files around, so in most cases, it is
easier to specify BuildRequires using the "tex(requirement.sty)" Provides.
If your package has a .tex file, look for the \usepackage{foo} lines, those
are your tex dependencies. And in some cases, those dependencies may be met
by local .sty files, so if you can't find a package in Fedora texlive that
Provides: tex(foo.sty), look for foo.sty in your package source. (It also
could be legitimately missing in Fedora, I'm clearly not perfect!)
Thanks,
Tom
On Wed, May 20, 2020 at 8:41 AM Richard Shaw wrote:
> On Wed, May 20, 2020 at 7:39 AM Richard Shaw wrote:
>
>> Not sure if this problem is related, but the last time I build
>> OpenImageIO it worked, I was performing a local mock build (with the local
>> repo enabled) and ran into this:
>>
>
> Correction, OpenColorIO. My fingers always want to type OpenImageIO :)
>
> Thanks,
> Richard
>
>> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
I'm hoping that when texlive is able to fully install this issue will go away. I just got a successful build for -21 that _should_ resolve all the broken deps except for biber. Tom On Fri, May 15, 2020 at 10:33 AM Orion Poplawski wrote: > On 5/14/20 10:48 PM, Orion Poplawski wrote: > > On 5/14/20 3:55 PM, Tom Callaway wrote: > >> I've just kicked off new builds for texlive and texlive-base for > >> TeXLive 2020 in rawhide. Hopefully, everything that depends on them > >> will continue to work, but if you notice any new issues generating > >> docs (or any missing components or broken dependencies), feel free to > >> email me or open Bugzilla tickets. > > > > I'm working on trying to fix the biber failure. It's an odd one that I > > cannot reproduce locally in mock. What I've been able to determine is > > that is appears that the "ls-R" files are not present in the koji > > buildroots for some reason. Perhaps this is an arch dependent thing > > since I seem to be landing on armv7 builders all the time. > > Well, it fails on an x86 builder as well so that's not it. I think > we're going to need to remove the stderr redirects and maybe add some > debugging in the scriptlets that build the ls-R files to try to see > what's failing there. But I think I'll leave this to others. > > -- > Orion Poplawski > Manager of NWRA Technical Systems 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
I'll get that fixed up first thing tomorrow. Apologies, Tom On Thu, May 14, 2020, 6:51 PM Miro Hrončok wrote: > On 14. 05. 20 23:55, Tom Callaway wrote: > > I've just kicked off new builds for texlive and texlive-base for TeXLive > 2020 in > > rawhide. Hopefully, everything that depends on them will continue to > work, but > > if you notice any new issues generating docs (or any missing components > or > > broken dependencies), feel free to email me or open Bugzilla tickets. > > This is temporary? > > > Problem: conflicting requests > > - nothing provides tex(ifpdf.sty) needed by > texlive-geometry-9:svn47638-19.fc33.noarch > > - nothing provides tex(atbegshi.sty) needed by > texlive-geometry-9:svn47638-19.fc33.noarch > > - nothing provides tex(ifvtex.sty) needed by > texlive-geometry-9:svn47638-19.fc33.noarch > > No package found for: tex(kvoptions.sty) > > Problem: package texlive-ucs-9:svn35853.2.2-19.fc33.noarch requires > tex(hyperref.sty), but none of the providers can be installed > > - conflicting requests > > - nothing provides tex(kvoptions.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(ifpdf.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(refcount.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(atbegshi.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(pdftexcmds.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(letltxmacro.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(auxhook.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(ltxcmds.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(pdfescape.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(gettitlestring.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(kvsetkeys.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(etexcmds.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(ifvtex.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(stringenc.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(bitset.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(hobsub-hyperref.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(hycolor.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(infwarerr.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(intcalc.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(kvdefinekeys.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > - nothing provides tex(rerunfilecheck.sty) needed by > texlive-hyperref-9:svn51742-19.fc33.noarch > > Problem: package texlive-amscls-9:svn46099-19.fc33.noarch requires > tex(amsfonts.sty), but none of the providers can be installed > > - conflicting requests > > - nothing provides tex-tetex needed by > texlive-amsfonts-9:svn29208.3.04-19.fc33.noarch > > - nothing provides texlive-tetex-bin needed by > texlive-amsfonts-9:svn29208.3.04-19.fc33.noarch > > Problem: package texlive-collection-latex-9:svn41614-19.fc33.noarch > requires texlive-psnfss, but none of the providers can be installed > > - conflicting requests > > - nothing provides tex-tetex needed by > texlive-psnfss-9:svn33946.9.2a-19.fc33.noarch > > - nothing provides texlive-tetex-bin needed by > texlive-psnfss-9:svn33946.9.2a-19.fc33.noarch > > https://koschei.fedoraproject.org/package/python-sphinx?collection=f33 > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TeXLive 2020 landing in rawhide
Just need that texlive build to finish and it should all clear up. Tom On Thu, May 14, 2020 at 6:13 PM Jerry James wrote: > On Thu, May 14, 2020 at 3:56 PM Tom Callaway wrote: > > I've just kicked off new builds for texlive and texlive-base for TeXLive > 2020 in rawhide. Hopefully, everything that depends on them will continue > to work, but if you notice any new issues generating docs (or any missing > components or broken dependencies), feel free to email me or open Bugzilla > tickets. > > > Well, koschei is currently bombarding me with emails about pretty much > every gap-pkg-* package to tell me that texlive-times cannot be > installed. For example: > > https://koschei.fedoraproject.org/package/gap-pkg-factint?collection=f33 > -- > Jerry James > http://www.jamezone.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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
TeXLive 2020 landing in rawhide
I've just kicked off new builds for texlive and texlive-base for TeXLive 2020 in rawhide. Hopefully, everything that depends on them will continue to work, but if you notice any new issues generating docs (or any missing components or broken dependencies), feel free to email me or open Bugzilla tickets. Thanks, Tom P.S. I have no plans to push this update to any stable branches, but if you really want the TL2020 magic, I'm running the F33 packages on my F32 system without 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
Re: The Chromium Dilemma
The linker said: error adding symbols: Malformed archive. Searching leads me to translate that error to "too many open files". See: https://github.com/OSSystems/meta-browser/issues/194 Apparently, gold does not have this issue, but I have not tested. Tom On Mon, Apr 13, 2020 at 12:05 PM Lennart Poettering wrote: > On Mo, 13.04.20 09:56, Tom Callaway (tcall...@redhat.com) wrote: > > > C) Chromium's build process gets...angrier. Still doable, but you have to > > do things like set ulimit -n 4096. (Fun fact: the man page section for > > ulimit says that for -n, "most systems do not allow this value to be > set". > > Guess modern Linux isn't most systems.) > > Hmm what precisely fails? > > Note that in systemd we took the liberty to bump RLIMIT_NOFILE's hard > limit to 512K a while back, which one can effectively understand as > "there's no limit on fds anymore" (this was on suggestion of some > kernel folks, because fds are these days tracked like memory and hence > are accounted like that too and are not as expensive as hey used to > be). We would have liked to bump the matching soft limit too (i.e. the > one you tweak with ulimit -n), but that's something what we can't do > without breaking compability a litte bit too agressively: fds above > 1023 are not compatible with select(), and plenty software still uses > select() (they really shouldn't, it's a terrible interface), and it's > a silent failure. > > Long story short: If there are programs that are likely to deal with > large numbers of fds (like in your case, the linker I presume?) they > should probably just bump the soft limit to the hard limit early on in > their C code, and thus just get as many fds they want. Raising the > soft limit up to the hard limit is an unprivileged operation and can > be done by regular users. Programs that do that should reset the soft > limit back to 1K before forking off foreign programs again though, > again for compatibility with any such programs that use select(). > > Very short version: consider filing a bug against your linker tool (or > whichever other tool needed the ulimit -n above), and ask them to set > RLIMIT_NOFILE's soft value to the hard value. And then they will just > work without any manual limit bumping for regular people on modern > distros. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
What I don't understand is _why_ RPM Fusion made that change. Not saying it is without merit, just that I don't understand why a total rebuild is preferred. I would also be interested in seeing the patches where you set a specific component to be shared while the others were static. Thanks, Tom On Mon, Apr 13, 2020 at 11:54 AM Kevin Kofler wrote: > Tom Callaway wrote: > > So, you might be asking, why does Fedora build in shared mode? There are > > two main reasons: > > 1) To enable users to be able to swap out the media components from > Fedora > > with a "freeworld" version. > > That reason is obsolete. RPM Fusion replaced chromium-libs-media-freeworld > with a full chromium-freeworld rebuild. > > > 2) To keep the size down on the chrome-remote-desktop subpackage (since > it > > can share the "internal libs" from chromium). > > That sounds valid, but is it worth the performance issues? > > I would recommend abandoning the component mode build. QtWebEngine has > never > been built that way. > > By the way, it is also possible to hack up the GN setup so that only some > specific component is built as a component (which could solve point 1 if > it > were still needed). For QtWebEngine, I used to do that with V8 on 32-bit > x86 > when I still had an x87 build and an SSE2 build of it. But that of course > requires patching. And RPM Fusion no longer tries to replace the media > component anyway (making point 1 moot). > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
https://browserbench.org/Speedometer2.0/ is the benchmark in the bug. Tom On Mon, Apr 13, 2020 at 10:34 AM Benson Muite wrote: > > > On Mon, Apr 13, 2020, at 5:21 PM, Michael Catanzaro wrote: > > Honestly, degraded performance is an expected result of doing component > > build, so I would say that's just not a bug at all, it's just how > > Chromium works. Our hand is forced here by upstream's strange and > > unusual packaging decisions. Other distros do it this way too. > > > > But you say the difference is *noticeable*, i.e. noticeable to users > > when not doing benchmarks? That sounds weird. > > > > On Mon, Apr 13, 2020 at 9:56 am, Tom Callaway > > wrote: > > > This is my dilemma. (It is not my only dilemma, nor my most pressing, > > > but it is still mine.) That said, I would love to get input from > > > other smart Fedorans as to what I should do here. > > > > Naive proposal: chromium-freeworld could completely rebuild Chromium > > and Obsoletes the entire Fedora package? It could have an epoch ahead > > of the Fedora package such that the rpmfusion version is always > > preferred even if the Fedora package updates a bit? Then > > chromium-libs-media-freeworld can go away and the main Fedora package > > can do a static build and you get working krb5. Is there a downside to > > this approach that I'm missing? > > > > > > Are the benchmark results available somewhere? What exactly was measured > in those benchmarks? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
The Chromium Dilemma
Hi Fedorans, Here's the situation: Recently, someone filed a bug against chromium, noting that it was benchmarking notably slower than Google Chrome or chromium-freeworld (from rpmfusion). I tested locally and confirmed it. They suspected that Fedora's optflags were to blame, but since chromium doesn't use them anymore, that wasn't it. chromium-freeworld enables some media codecs we cannot, but this shouldn't affect javascript benchmark tests. VAAPI is turned on in both builds, but not in Google Chrome. Ultimately, the culprit was in how chromium is built for Fedora. There are two ways to build chromium: as a giant static binary (which is how Google Chrome and chromium-freeworld are built) and as a collection of shared libraries (which is how Fedora's chromium is built). I did a test build of a static version of Fedora's chromium and the benchmark performance went up to expected levels. It's worth noting that IMHO, the performance loss is noticeable, but the browser is still usable. So, you might be asking, why does Fedora build in shared mode? There are two main reasons: 1) To enable users to be able to swap out the media components from Fedora with a "freeworld" version. 2) To keep the size down on the chrome-remote-desktop subpackage (since it can share the "internal libs" from chromium). Switching to static mode gives us: 1) Fully working krb5 (because it would resolve the symbol clash caused by the use of chromium's boringssl fork). This bug has been outstanding for a few years now. 2) Performance improvements. HOWEVER, switching to static mode means that: A) It will become impossible to have an addon package from rpmfusion (or wherever) to swap in the additional media codecs we cannot include in Fedora. The only way to get those codecs would be to install an alternate build of chromium (chromium-freeworld) or a different browser (Fedora). Hypothetically, it might be possible to try to patch chromium to build _just_ the media bits as a shared library (or to have it dlopen them), but upstream is not in the slightest way interested in that, and untangling the Lovecraftian nightmare that is the custom Chromium buildsystem is not my idea of a fun quarantine activity. Full disclosure here: rpmfusion has not really been doing builds of this addon package (chromium-libs-media-freeworld) for quite some time now. I'm not sure why. This means that at least for the last few months, this option hasn't really been available to anyone outside of people doing manual rebuilds of the chromium SRPM with the %freeworld and %shared variables enabled. B) Per process memory utilization for chromium might go up. Not sure about this. C) Chromium's build process gets...angrier. Still doable, but you have to do things like set ulimit -n 4096. (Fun fact: the man page section for ulimit says that for -n, "most systems do not allow this value to be set". Guess modern Linux isn't most systems.) Now, we could make a chromium-static subpackage (just 4-6 more hours added to the koji build), but I'm concerned that users would not understand the purpose of it, and even if they did, they'd get unhappy when they discovered that it had missing codecs. There are a large number of web services that convert GIF animations to embedded videos these days, and most of them aren't using codecs we can ship (hi Twitter). This is my dilemma. (It is not my only dilemma, nor my most pressing, but it is still mine.) That said, I would love to get input from other smart Fedorans as to what I should do here. Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC help needed for chromium
Confirmed, that gcc builds a working chromium. Thank you so much.
Tom
On Thu, Mar 12, 2020 at 6:39 AM Jakub Jelinek wrote:
> On Mon, Mar 02, 2020 at 08:57:46AM -0500, Tom Callaway wrote:
> > Wait, I know that $TOPIC is scary, come back.
> >
> > Chromium has this chunk of code (in
> > third_party/angle/src/common/PackedEnums.h):
> >
> > // This horrible const_cast pattern is necessary to work
> > around a constexpr limitation.
> > // See https://stackoverflow.com/q/34199774/ . Note that it
> > should be fixed with C++17.
> > const_cast(const_cast(
> > mPrivateData)[static_cast(it->first)]) =
> > it->second;
> >
> > This code built with gcc9, but with gcc10 it no longer works.
>
> Please try gcc-10.0.1-0.9.fc{32,33} (f32 version hasn't finished building
> yet though).
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC help needed for chromium
e/src/libGLESv2/entry_points_gles_ext_autogen.cpp:14: ../../third_party/angle/src/libANGLE/Context.inl.h:36:2: note: originally declared 'const' here 36 | }}; | ^ As requested, preprocessed sources (gcc -E) from gcc 9.2.0 and gcc-10.0.1-0.8.fc32.x86_64 are available here: https://spot.fedorapeople.org/entry_points_gles_ext_autogen.E.gcc9 https://spot.fedorapeople.org/entry_points_gles_ext_autogen.E.gcc10 I think this failure is occurring because of this reference in the GCC10 changelog: * G++ can now detect modifying constant objects in constexpr evaluation (which is undefined behavior). I understand that it is undefined behavior in the C++14 standard, but given that it is explicitly permitted in C++17 (and that it was implicitly permitted with this hack in C++14), it feels like this is a regression. Nevertheless, I would appreciate any help in resolving this so that we have a working Chromium in Fedora 32. Thanks in advance, Tom On Mon, Mar 2, 2020 at 9:16 AM Jakub Jelinek wrote: > On Mon, Mar 02, 2020 at 08:57:46AM -0500, Tom Callaway wrote: > > Wait, I know that $TOPIC is scary, come back. > > > > Chromium has this chunk of code (in > > third_party/angle/src/common/PackedEnums.h): > > > > // This horrible const_cast pattern is necessary to work > > around a constexpr limitation. > > // See https://stackoverflow.com/q/34199774/ . Note that it > > should be fixed with C++17. > > const_cast(const_cast( > > mPrivateData)[static_cast(it->first)]) = > > it->second; > > > > This code built with gcc9, but with gcc10 it no longer works. > > Is it now rejected with some error (which)? > Generally, such code snippets aren't really very useful because they lack > context, so what we really need is full preprocessed sources + g++ command > line options used to reproduce it, if gcc9 built and gcc10 doesn't, best > preprocessed sources from both gcc 9 and gcc 10, so that we can find out if > it is a header change or compiler change that matters. > > Jakub > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
GCC help needed for chromium
Wait, I know that $TOPIC is scary, come back. Chromium has this chunk of code (in third_party/angle/src/common/PackedEnums.h): // This horrible const_cast pattern is necessary to work around a constexpr limitation. // See https://stackoverflow.com/q/34199774/ . Note that it should be fixed with C++17. const_cast(const_cast( mPrivateData)[static_cast(it->first)]) = it->second; This code built with gcc9, but with gcc10 it no longer works. I've tried two ways to fix this: A) Changing that line of code to: mPrivateData[static_cast(it->first)] = it->second; AND Building all of chromium with -std=c++17 This results in a chromium that builds but segfaults immediately: Stack trace of thread 333141: #0 0x56480cc9b2d8 _Z41__static_initialization_and_destruction_0ii.constprop.0 (chromium-browser + 0x6b82d8) #1 0x56480f130dfd __libc_csu_init (chromium-browser + 0x2b4ddfd) #2 0x7f0a04a2cfce __libc_start_main (libc.so.6 + 0x26fce) #3 0x56480ccaf21e _start (chromium-browser + 0x6cc21e) B) Cheating and accessing the std::array's underlying array directly (thanks to Raphael Kubo Da Costa for the idea): mPrivateData._M_elems[static_cast(it->first)] = it->second; That change enables chromium to build, but it segfaults in the same way. Now, it's possible that this change is a red herring and that something else in GCC10 is causing the segfault, but I'm out of ideas on how to proceed. If someone with GCC knowhow could help out here, it would be greatly appreciated. Thanks in advance, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Retired] gstreamer & gstreamer-plugins-base
Yes, I did. Apologies. Tom On Fri, Jan 31, 2020 at 8:41 AM Michael Catanzaro wrote: > On Fri, Jan 31, 2020 at 8:37 am, Tom Callaway > wrote: > > * There are significant improvements in the gstreamer0.10 branch > > (which is separately packaged and maintained in Fedora) > > You meant to write "gstreamer1", yes? > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Retired] gstreamer & gstreamer-plugins-base
Since I've moved my last dependent package off of this old stack, I've retired gstreamer & gstreamer-plugins-base in rawhide (again). Before reviving these poor and tired packages, please consider the following: * Upstream is not maintaining this code branch anymore. * There are significant improvements in the gstreamer0.10 branch (which is separately packaged and maintained in Fedora) Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Big change to free maxmind GeoLite2 databases, limiting distribution
FWIW, I am investigating the geolite2 license situation with Red Hat. Thanks, Tom On Mon, Jan 6, 2020 at 4:45 PM Dave Dykstra wrote: > I see that currently Fedora rawhide gets new geolite2-*-YYYMMDD packages > (e.g. geolite2-city-20191217) each month in order to distribute the free > maxmind geo IP databases. Unfortunately, Maxmind just greatly tightened > down on the license for these data distributions and I think that Fedora > will no longer be able to distribute them. The databases may still be > downloaded for free, and they may be freely redistributed, but anybody > who does so must ensure that everybody that they distribute to updates > their database within 30 days after Maxmind updates them, and destroys > all old copies. Here's the blog entry where they announced the change, > late in December, effective the end of 2019, saying that they had to do > it because of privacy laws: > > https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ > > Anybody may sign up for an account and free license key, but they have to > agree to The new End User License Agreement with the new stipulations. > https://www.maxmind.com/en/geolite2/eula > > I welcome any suggestions for good alternative sources of geo IP data > that doesn't have these kinds of restrictions and also believes they can > adhere to the privacy laws without requiring a license key. > > Dave > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: List of long term FTBFS packages to be retired in February (release candidate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The only living packages from this list without current f31 or rawhide builds: elasticsearch (gradle hellscape) expresso (abandoned upstream) infinispan (lots of deps orphaned) shim-unsigned-aarch64 (will let pjones handle) shim-unsigned-x64 (will let pjones handle) golang-gopkg-sourcemap was renamed to golang-gopkg-sourcemap-1 libocrdma was obsoleted by rdma-core nuvola-app-groove is dead because Microsoft Groove was discontinued at the end of 2017 owncloud is dead due to orphaning for 6+ weeks yaws is dead due to orphaning for 6+ weeks All the others have f31 or f32 builds. Tom -BEGIN PGP SIGNATURE- Version: FlowCrypt 7.3.4 Gmail Encryption Comment: Seamlessly send and receive encrypted email wkYEAREIAAYFAl39MHcACgkQPF6ZrZMFQmDgfgCgghbHvY/+OiuR8Cgk3Yb1 vilsEmMAoJJEySdo2H9wL4bOybG9ifhpngyo =NOCI -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: List of long term FTBFS packages to be retired in February (release candidate)
I fixed dnssec-nodes (and dnssec-tools), gnomint, lilyterm, rubygem-connection_pool, rubygem-session, target-isns, tcmu-runner, telepathy-gabble, and telepathy-salut in rawhide. I thought about fixing elasticsearch, but there is not enough alcohol for me to touch a gradle package. Thanks, Tom On Sun, Dec 15, 2019 at 6:10 AM Miro Hrončok wrote: > Dear maintainers. > > Based on the latest fail to build from source policy, the following > packages > will be retired from Fedora 32 approximately one week before branching > (February > 2020). > > Policy: > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > The packages in rawhide were not successfully built at least since Fedora > 30. > > This report is based on dist tags and represents a preliminary list of > packages. > > Packages collected via: > > https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb > > The main purpose is to gather feedback. > > If you see a package that was built, please let me know. > If you see a package that should be exempted from the process, please let > me > know and we can work together to get a FESCo approval for that. > > If you see a package that can be rebuilt, please do so. > > Package (co)maintainers Latest > build > > > dnssec-nodes hardaker Fedora > 27 > elasticsearch hubbitus, jvanek, lbazan,Fedora > 24 >zbyszek > expresso jamielinux, nodejs-sig, Fedora > 28 >patches > gnomint verdurin Fedora > 24 > libocrdma ocrdma Fedora > 27 > lilyterm cwickert Fedora > 27 > nuvola-app-google-calendarmartinkg Fedora > 29 > nuvola-app-groove martinkg Fedora > 28 > nuvola-app-logitech-media-martinkg Fedora > 29 > server > nuvola-app-plex martinkg Fedora > 29 > nuvola-app-soundcloud martinkg Fedora > 29 > nuvola-app-yandex-music martinkg Fedora > 29 > rubygem-connection_pool anujmore Fedora > 24 > rubygem-session gomixFedora > 29 > shim-unsigned-aarch64 pjones Fedora > 28 > shim-unsigned-x64 pjones Fedora > 28 > target-isns grover, mlombard Fedora > 27 > tcmu-runner mlombard Fedora > 26 > telepathy-gabble aperezbios Fedora > 29 > telepathy-salut aperezbios, johnpFedora > 29 > > The following packages require above mentioned packages: > Depending on: expresso (1) > nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh) > nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = > 0.9.2 > > Depending on: rubygem-connection_pool (45) > rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch) > rubygem-activestorage-5.2.3-3.fc31.src requires > rubygem(connection_pool) = 2.2.0-1 > > rubygem-activesupport (maintained by: jaruga, jstribny, kanarip, > mmorsi, > pvalena, ruby-packagers-sig, sseago, vondruch) > rubygem-activesupport-1:5.2.3-2.fc31.src requires > rubygem(connection_pool) = > 2.2.0-1 > > rubygem-rails (maintained by: jstribny, kanarip, mmorsi, mtasaka, > pvalena, > ruby-packagers-sig, sseago, tdawson, vondruch) > rubygem-rails-1:5.2.3-2.fc31.noarch requires > rubygem(activestorage) = 5.2.3 > > rubygem-railties (maintained by: mmorsi, pvalena, vondruch) > rubygem-railties-5.2.3-3.fc31.src requires > rubygem(activestorage) = 5.2.3 > > rubygem-actionpack (maintained by: jaruga, jstribny, kanarip, > mmorsi, pvalena, > ruby-packagers-sig, sseago, vondruch) > rubygem-actionpack-1:5.2.3-3.fc31.noarch requires > rubygem(activesupport) = 5.2.3 > rubygem-actionpack-1:5.2.3-3.fc31.src requires > rubygem(activesupport) = 5.2.3 > > rubygem-actionview (maintained by: jaruga, pvalena, > ruby-packagers-sig) > rubygem-actionview-5.2.3-3.fc31.noarch requires > rubygem(activesupport) = 5.2.3 > rubygem-actionview-5.2.3-3.fc31.src requires > rubygem(activesupport) = 5.2.3 > > rubygem-activejob (maintained by: pvalena, vondruch) >
scalapack 2.1 in rawhide
Hi Fedorans, With the new upstream release of 2.1, the Fedora scalapack package in rawhide is switching over to use the upstream provided cmake infrastructure (instead of the Makefiles I built many years ago). As a result, there is no longer a separate libmpiblacs library, but all of the symbols that used to live in libmpiblacs are inside libscalapack. The following packages no longer exist in rawhide (and are Provided/Obsoleted by the corresponding scalapack packages): * blacs-common * blacs-mpich * blacs-mpich-devel * blacs-mpich-static * blacs-openmpi * blacs-openmpi-devel * blacs-openmpi-static The impact of this change is minimal, but not zero. I kicked off rebuilds of cp2k, gpaw and MUMPS that reflect this change. Please open bugs against scalapack if you have any problems as a result of this change. Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Claiming recently orphaned packages
I'm claiming (and fixing FTBFS) on busybox and sqlite2. https://pagure.io/releng/issue/9009 https://pagure.io/releng/issue/9010 Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review swap?
I could use a quick review for a new R package: R-Rhtslib https://bugzilla.redhat.com/show_bug.cgi?id=1767062 Can do a review or other packaging/legal/license favors in trade. Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Confusing chromium build failures in EPEL8
Never mind. I was confused by the fact that epel-8 kicks off two builds for some reason. Looking in the wrong log. Now I get to figure out why gnome-keyring-devel doesn't exist in EPEL8. Tom On Fri, Sep 6, 2019 at 11:12 AM Tom Callaway wrote: > Building chromium-76.0.3809.132-3.el8 for epel8-candidate > Created task: 37499863 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=37499863 > > It fails with: > 37499910 buildArch (chromium-76.0.3809.132-3.el8.src.rpm, x86_64): open ( > buildhw-03.phx2.fedoraproject.org) -> FAILED: BuildError: error building > package (arch x86_64), mock exited with status 30; see root.log for more > information > 0 free 2 open 2 done 2 failed > > But I can't see any reason why in the root.log. Any thoughts? > > Thanks in advance, > Tom > > ___ 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
[EPEL-devel] Confusing chromium build failures in EPEL8
Building chromium-76.0.3809.132-3.el8 for epel8-candidate Created task: 37499863 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=37499863 It fails with: 37499910 buildArch (chromium-76.0.3809.132-3.el8.src.rpm, x86_64): open ( buildhw-03.phx2.fedoraproject.org) -> FAILED: BuildError: error building package (arch x86_64), mock exited with status 30; see root.log for more information 0 free 2 open 2 done 2 failed But I can't see any reason why in the root.log. Any thoughts? Thanks in advance, Tom ___ 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
Reviving torque
I'm going to revive torque (one of my packages depends on it). Looks like it was abandoned by the old maintainer, but the fix to get it building again was trivial (missing a tex BuildRequires). If there are any reasons not to, speak up, please. Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
gstreamer-plugins-base revival
I'm hoping that this one hasn't been dead for 8 weeks, because all it needs to get it building again is to disable the gtk-doc generation... I don't really want to own it, but I have dependent packages, so if no one else does, I will claim it. If you want it (or know of some reason it shouldn't be brought back), please speak up. Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How do I remove GLIBCXX_ASSERTIONS?
I think this is what you want:
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS / /')
Tom
On Fri, Aug 2, 2019 at 11:00 AM Steven A. Falco
wrote:
> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS
> from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448
>
> What is the best way to do that? I can add "%undefine _hardened_build"
> (which I am testing now) but I think that will remove other hardening
> features that I might want to leave enabled.
>
> Steve
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
s390x rawhide issues?
One of my packages (alienarena) fails to build in rawhide on s390x (and only that arch), but the build log shows it never even starts. When I look at the root log, I see this: DEBUG util.py:585: BUILDSTDERR: error: unpacking of archive failed on file /builddir/build/SOURCES/alienarena-7.71.0-svn5638.tar.xz;5d41b327: cpio: read failed - Inappropriate ioctl for device DEBUG util.py:585: BUILDSTDERR: error: /builddir/build/originals/alienarena-7.71.0-3.fc31.src.rpm cannot be installed Is something unhappy on s390x on rawhide? Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=36706646 Thanks in advance, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: glibc-arm-linux-gnu help
Reviving this. I do not have the time nor the energy to attempt to keep this going, so I am going to disable the shared bits in cross-gcc and kill off glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be seriously impacted by this. If you are, I suggest using this copr instead: https://copr.fedorainfracloud.org/coprs/lantw44/arm-linux-gnueabi-toolchain/ ~tom On Wed, Nov 7, 2018 at 11:02 AM Tom Callaway wrote: > > > On 11/7/18 11:00 AM, Tom Callaway wrote: > > A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could > > have a packaged arm cross-toolchain that was useful (with glibc, it > > cannot build anything in userspace) > > This should have read "without glibc, it cannot build anything in > userspace". > > ~tom > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Retiring v8-314
Hey, remember when I said I would keep v8-314 alive? I've changed my mind. Why? A) It is seriously old. I'm not sure I want to encourage anyone to try to use it at this point. B) Upstream v8 looks NOTHING like this package anymore C) It doesn't build anymore because the giant SConstruct goop it uses is not compatible with the current SCons. (and it has not built for quite a while now). D) I have neither the time nor the motivation to do the work to make it build again I think there is some effort to enable v8 headers out of the nodejs bundled copy, which seems like a much smarter approach, since node is actually maintaining that v8 codebase. Alternately, the v8 upstream intends for their code to be a "copylib", which I find disgusting, but not so much that it outweighs the disgust level in v8-314. TLDR: v8-314 is old, deserves to die, so i killed it ~tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
The odd thing is that this compiler flag is hardcoded into the build by the upstream. I'm wondering why Fedora hits this when no one else seems to. I mean, I'm fine to disable it, because the Chromium codebase is a tomb of horrors anyway, and if I have to sacrifice that flag to make it happy, so be it. ~tom On Wed, Mar 13, 2019 at 10:37 AM Jakub Jelinek wrote: > On Wed, Mar 13, 2019 at 10:28:29AM -0400, Tom Callaway wrote: > > I tried removing some of the compiler flags to see if I could identify > what > > might be triggering this, and removing "-fno-delete-null-pointer-checks" > > seems to make this error vanish. > > -fno-delete-null-pointer-checks is certainly an option that requests that > the compiler does not fold comparisons against NULL at compile time based > on > assumption that objects have non-NULL address, so sure, if it has such > asserts, > it is incompatible with that option, you can't have both. > > Jakub > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
I tried removing some of the compiler flags to see if I could identify what
might be triggering this, and removing "-fno-delete-null-pointer-checks"
seems to make this error vanish.
Not sure if that helps or not, but hopefully, I can get this beast building
without it.
Thanks,
Tom
On Mon, Mar 11, 2019 at 1:31 PM Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 01:16:07PM -0400, Tom Callaway wrote:
> > I spent some time this weekend trying to get Chromium 72 building on
> > Fedora, but I kept running into a C++ issue that I was not able to
> resolve.
> > This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>
> Can you please provide preprocessed source + g++ command line options,
> from the snippets it is hard to see what's going on.
> From the description it seems maybe like:
> template
> struct S {
> static constexpr int a[2] = { 1, 2 };
> };
> static_assert (<0>::a[1] != nullptr);
>
> which g++ accepts for -std=c++{11,14} but rejects for -std=c++{17,2a} when
> S<0>::a is an inline variable. I think we have a similar
> http://gcc.gnu.org/PR89074 . The middle-end punts here and doesn't
> optimize
> the != NULL to true because it is address of a comdat variable and thus it
> in the end could come up from any other TU. Though perhaps in these cases
> the standard gives us some guarantees.
>
> Jakub
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
FWIW, I did. There is no fix there.
~tom
On Mon, Mar 11, 2019 at 1:20 PM Vascom wrote:
> Look at chromium-vaapi build in rpmfusion.
>
> пн, 11 мар. 2019 г., 20:17 Tom Callaway :
>
>> Hi folks,
>>
>> I spent some time this weekend trying to get Chromium 72 building on
>> Fedora, but I kept running into a C++ issue that I was not able to resolve.
>> This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>>
>> Here's a sample of the error (it happens in a few places), from Fedora 30:
>>
>> In file included from
>> ../../base/trace_event/trace_event_system_stats_monitor.h:15,
>> from ../../base/trace_event/trace_event.h:26,
>> from ../../base/threading/scoped_blocking_call.cc:11:
>> ../../base/trace_event/trace_log.h: In constructor
>> 'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
>> ../../base/threading/scoped_blocking_call.cc:88:5: in 'constexpr'
>> expansion of
>> 'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
>> char*)"base"))'
>> ../../base/trace_event/trace_log.h:215:25: error: '((&
>> base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
>> constant expression
>> 215 | if (builtin_category)
>> | ^
>>
>> Now, chromium isn't the easiest code base to work with, but what seems to
>> be happening is that this code calls one of the TRACE_EVENT macros, like
>> this from base/threading/scoped_blocking_call.cc:
>>
>> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
>> static_cast(blocking_type));
>>
>> Those macros are defined in base/trace_event/common/trace_event_common.h:
>>
>> #define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val)
>> \
>> INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name,
>> \
>>TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
>>
>> INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
>>
>> / Implementation detail: internal macro to create static category and add
>> // event if the category is enabled.
>> #define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags,
>> ...) \
>> do {
>> \
>> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);
>> \
>> if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) {
>> \
>> trace_event_internal::AddTraceEvent(
>> \
>> phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name,
>> \
>> trace_event_internal::kGlobalScope,
>> trace_event_internal::kNoId, \
>> flags, trace_event_internal::kNoId, ##__VA_ARGS__);
>> \
>> }
>> \
>> } while (0)
>>
>> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
>> base/trace_event/trace_event.h:
>>
>> #define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
>> \
>> static_assert(
>> \
>>
>> base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
>> "Unknown tracing category is used. Please register your "
>> \
>> "category in base/trace_event/builtin_categories.h");
>> \
>> constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
>> \
>> k_category_group_enabled) =
>> \
>>
>> base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group); \
>> const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
>> \
>> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
>> \
>> category_group,
>> INTERNAL_TRACE_EVENT_UID(k_category_group_enabled), \
>> INTERNAL_TRACE_EVENT_UID(category_group_enabled));
>>
>> Finally, inside here, it
>> calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
>> defined in base/trace_event/trace_log.h:
>>
>> // Called by TRACE_EVENT* macros, don't call this directly.
>> // The name parameter is a category group for example:
>> // TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
>> static const unsigned char* GetCategoryGroupEnabled(const char* name);
>> static const char* GetCategoryGroupName(
>> const unsigned char* category_group_enabled);
>> static constexpr const unsigned char* GetBuiltinCategoryEnabled(
>> const char* name) {
>> TraceCategory* builtin_cate
Chromium C++ help needed
Hi folks,
I spent some time this weekend trying to get Chromium 72 building on
Fedora, but I kept running into a C++ issue that I was not able to resolve.
This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
Here's a sample of the error (it happens in a few places), from Fedora 30:
In file included from
../../base/trace_event/trace_event_system_stats_monitor.h:15,
from ../../base/trace_event/trace_event.h:26,
from ../../base/threading/scoped_blocking_call.cc:11:
../../base/trace_event/trace_log.h: In constructor
'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
../../base/threading/scoped_blocking_call.cc:88:5: in 'constexpr'
expansion of
'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
char*)"base"))'
../../base/trace_event/trace_log.h:215:25: error: '((&
base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
constant expression
215 | if (builtin_category)
| ^
Now, chromium isn't the easiest code base to work with, but what seems to
be happening is that this code calls one of the TRACE_EVENT macros, like
this from base/threading/scoped_blocking_call.cc:
TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
static_cast(blocking_type));
Those macros are defined in base/trace_event/common/trace_event_common.h:
#define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val) \
INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name, \
TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
/ Implementation detail: internal macro to create static category and add
// event if the category is enabled.
#define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags, ...) \
do { \
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);\
if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) { \
trace_event_internal::AddTraceEvent( \
phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name, \
trace_event_internal::kGlobalScope, trace_event_internal::kNoId, \
flags, trace_event_internal::kNoId, ##__VA_ARGS__); \
} \
} while (0)
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
base/trace_event/trace_event.h:
#define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
\
static_assert(
\
base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
"Unknown tracing category is used. Please register your "
\
"category in base/trace_event/builtin_categories.h");
\
constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
\
k_category_group_enabled) =
\
base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group); \
const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
\
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
\
category_group, INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),
\
INTERNAL_TRACE_EVENT_UID(category_group_enabled));
Finally, inside here, it
calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
defined in base/trace_event/trace_log.h:
// Called by TRACE_EVENT* macros, don't call this directly.
// The name parameter is a category group for example:
// TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
static const unsigned char* GetCategoryGroupEnabled(const char* name);
static const char* GetCategoryGroupName(
const unsigned char* category_group_enabled);
static constexpr const unsigned char* GetBuiltinCategoryEnabled(
const char* name) {
TraceCategory* builtin_category =
CategoryRegistry::GetBuiltinCategoryByName(name);
if (builtin_category)
return builtin_category->state_ptr();
return nullptr;
}
Okay, so what seems like is happening here, is that the calls like this:
TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
static_cast(blocking_type));
Are passing "base" (that first var) all the way into
GetCategoryGroupEnabled, which is finding it via GetBuiltinCategoryByName()
in base/trace_event/category_registry.h, checking against the list in
INTERNAL_TRACE_LIST_BUILTIN_CATEGORIES(X)
from base/trace_event/builtin_categories.h, finding it, then returning this
as builtin_category:
(& base::trace_event::CategoryRegistry::categories_[7])
When if(builtin_category) is run (trying to check to see if we got a
buillt-in category or a nullptr, I think), thats when GCC says:
error: '((& base::trace_event::CategoryRegistry::categories_[7]) != 0)' is
not a constant expression
*
None of the other distros that
Re: undefined symbol: shm_open (ppc64le and aarch64)
On 2/6/19 8:28 PM, Mamoru TASAKA wrote: > I don't know well about R, however that is probably because R-core > (-3.5.3-4.fc30) package already > requires librt.so on x86_64, i686, etc, while on aarch64 and ppc64le, it > does not, which probably indicates > that on x86_64, i686, etc R binary is already linked with librt.so , > while on aarch64 and ppc64le > it is not. > > So probably on x86_64, i686 when dlopen()ing BiocParallel.so symbol for > shm_open is already resolved > (because R is linked against librt.so) while on aarch64 and ppc64le it > is not. > > I guess this is because there is some configuration difference on R.spec > on aarch64 and > ppc64le. So, R links with rt if this configure check succeeds: AC_CHECK_LIB(rt, clock_gettime) Sure enough, on aarch64 and ppc64le, there is no clock_gettime in librt.so.1. I'm not sure _why_, but there is probably a good reason. I now understand why these builds are failing and have several paths to workaround it. Thanks! ~tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
undefined symbol: shm_open (ppc64le and aarch64)
One of my packages failed the mass rebuild, but only on ppc64le and aarch64. The error they both hit is this: Error: package or namespace load failed for 'BiocParallel' in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '/builddir/build/BUILDROOT/R-BiocParallel-1.16.5-1.fc30.ppc64le/usr/lib64/R/library/BiocParallel/libs/BiocParallel.so': /builddir/build/BUILDROOT/R-BiocParallel-1.16.5-1.fc30.ppc64le/usr/lib64/R/library/BiocParallel/libs/BiocParallel.so: undefined symbol: shm_open Error: loading failed Here's the linker invocation: g++ -m64 -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o BiocParallel.so ipcmutex.o -L/usr/lib64/R/lib -lR Now, google says this might be due to a lack of -lrt, but what's not clear to me is why it only fails on these two architectures (I've confirmed that none of the others have -lrt either). Full build logs are here: https://koji.fedoraproject.org/koji/taskinfo?taskID=32581444 Thanks in advance, ~tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[rpms/perl-Alien-wxWidgets] PR #1: Remove BR on wxGTK as it is about to be retired
spot merged a pull-request against the project: `perl-Alien-wxWidgets` that you are following. Merged pull-request: `` Remove BR on wxGTK as it is about to be retired `` https://src.fedoraproject.org/rpms/perl-Alien-wxWidgets/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Server Side Public License (SSPL) v1
After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk. It is also worth nothing that while there is a draft for a "v2" of the SSPL: A) It is not final. B) It is not in use anywhere at this time (as far as we know). C) The intent of the v2 draft text is not changed from the v1 license currently in use. We have updated our "Bad License" list to include SSPLv1. No software under that license may be included in Fedora (including EPEL and COPRs). Thanks, Tom Callaway Fedora Legal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Reviews needed
When I wasn't looking, asymptote grew a new dependency, which means I have two new packages that need reviews. python-speg: https://bugzilla.redhat.com/show_bug.cgi?id=1663036 python-cson: https://bugzilla.redhat.com/show_bug.cgi?id=1663037 They're very small, very simple packages. Should take about a minute to review. Will trade reviews or other packaging favors. tia, ~tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[rpms/perl-Email-MessageID] PR #1: Remove unneeded requirement
spot canceled a pull-request against the project: `perl-Email-MessageID` that you are following. Cancelled pull-request: `` Remove unneeded requirement `` https://src.fedoraproject.org/rpms/perl-Email-MessageID/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
