Re: Fedora 35 security update of curl blocked for a month
On Thursday, November 4, 2021 2:07:53 AM CET Adam Williamson wrote: > On Wed, 2021-11-03 at 09:38 -0700, Adam Williamson wrote: > > > and that its > > > > > > subject nor the body contained any information besides the (currently > > > valid) URL to some JSON data. > > > > I don't recall exactly how this part works, but it's *probably* because > > this is broken: > > > > https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/blob/dev > > elop/fedmsg_meta_fedora_infrastructure/waiverdb.py#L33-L36 > > > > note it tries to use the key 'result_id' from the message, but current > > waiverdb.waiver.new messages do not seem to include that field. > > This should fix it: > https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/508 Thank you for working on it! Kamil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 security update of curl blocked for a month
Sounds interesting. Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[Bug 2017154] perl-Spreadsheet-XLSX-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2017154 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.fc35 |1.fc35 |perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.el8 |1.el8 ||perl-Spreadsheet-XLSX-0.16- ||1.fc33 --- Comment #13 from Fedora Update System --- FEDORA-2021-f10ded5d20 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2017154 ___ 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
Re: ocaml-* (was: Re: Orphaned packages looking for new maintainers)
On Wed, Nov 3, 2021 at 3:44 AM Richard W.M. Jones wrote: > On Mon, Oct 25, 2021 at 12:41:59PM +0200, Miro Hrončok wrote: > > ocaml-charinfo-width orphan 2 weeks > > ago > > ocaml-cmdlinerorphan 2 weeks > > ago > > ocaml-cudforphan 2 weeks > > ago > > ocaml-lambda-term avsej, orphan2 weeks > > ago > > ocaml-lwt-log orphan 2 weeks > > ago > > ocaml-mmaporphan 2 weeks > > ago > > ocaml-ocplib-endian orphan 2 weeks > > ago > > ocaml-result andyli, orphan, rjones 2 weeks > > ago > > ocaml-zed orphan 2 weeks > > ago > > I took all of these, co-maintainers would be very welcome. I'm willing to comaintain if you like. Regards, -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 status and testing needed
Look at your first screen shot. When discs have data or other OSs on them, Anaconda tries to not disturb existing data. You must select “make additional space available” before the installer can progress. Anaconda is not like other installers. Often, users from the Debian world have trouble with Anaconda. I got hung up on this the first time I set up Fedora 29. Original Message On Nov 3, 2021, 3:58 PM, Jun Aruga wrote: > On Mon, Oct 25, 2021 at 11:03 AM Jun Aruga wrote: >> >> On Mon, Oct 25, 2021 at 10:33 AM Samuel Sieb wrote: >> > >> > On 2021-10-25 01:21, Jun Aruga wrote: >> > > I might find the issues about installation with the Fedora 35 64-bit >> > > network install image. How and where can I report it? >> > > Is the beta installation too old to test now? Thanks. >> > > https://getfedora.org/en/workstation/download/ >> > >> > The test list (t...@lists.fedoraproject.org) is the place to discuss not >> > yet released Fedora versions. Beta is too old. There should be RC >> > images somewhere. >> >> OK. Thanks for the info. > > 4 days ago, before Fedora 35 final release, I tried Fedora 35 RC 1.2 > installer. > Then I saw one issue in the case that my Laptop has one 2 TB SSD and > one 250 GB USB disk. > As I couldn't find how to report this report, I wrote the issue with > some images. > > Fedora 35 RC1.2 installer: “Not enough free space on selected disks.” > on selecting 2 disks > https://discussion.fedoraproject.org/t/34110 > > -- > Jun | He - Him > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
[Bug 2017154] perl-Spreadsheet-XLSX-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2017154 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.fc35 |1.fc35 |perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.el8 |1.el8 |perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.fc33 |1.fc33 |perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.fc34 |1.fc34 ||perl-Spreadsheet-XLSX-0.16- ||1.el7 --- Comment #15 from Fedora Update System --- FEDORA-EPEL-2021-24c1957e4f has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2017154 ___ 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
[Bug 2017154] perl-Spreadsheet-XLSX-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2017154 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.fc35 |1.fc35 |perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.el8 |1.el8 |perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.fc33 |1.fc33 ||perl-Spreadsheet-XLSX-0.16- ||1.fc34 --- Comment #14 from Fedora Update System --- FEDORA-2021-c2e135abb1 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2017154 ___ 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
Re: Fedora 35 security update of curl blocked for a month
On Wed, 2021-11-03 at 09:38 -0700, Adam Williamson wrote: > > > and that its > > subject nor the body contained any information besides the (currently > > valid) > > URL to some JSON data. > > I don't recall exactly how this part works, but it's *probably* because > this is broken: > > https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/blob/develop/fedmsg_meta_fedora_infrastructure/waiverdb.py#L33-L36 > > note it tries to use the key 'result_id' from the message, but current > waiverdb.waiver.new messages do not seem to include that field. This should fix it: https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/508 -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 security update of curl blocked for a month
On Wed, Nov 03, 2021 at 09:38:57AM -0700, Adam Williamson wrote: ...snip... > > I'll send a patch to fix that. Of course, what we're *really* behind on > here is getting datagrepper and FMN rewritten to use fedora-messaging > and message schemas[0] instead of fedmsg and the fedmsg_meta stuff... > > [0] https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema So, just FYI on this part... CPE folks actually worked on modernizing datanommer/datagrepper recently: https://pagure.io/cpe/initiatives-proposal/issue/8 The database is currently being migrated from just postgres to timescaledb, but it's a gigantic db and it's taking a long time to do so. Hopefully it will be finished by the end of the year... I really hope we get around to FMN soon... it's really ancient at this point and has a lot of problems. ;( kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2017154] perl-Spreadsheet-XLSX-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2017154 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Spreadsheet-XLSX-0.16- |perl-Spreadsheet-XLSX-0.16- |1.fc35 |1.fc35 ||perl-Spreadsheet-XLSX-0.16- ||1.el8 --- Comment #12 from Fedora Update System --- FEDORA-EPEL-2021-10d5b10539 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2017154 ___ 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
wiki talk pages editing disabled
Greetings everyone. I've disabled editing of our mediawiki "iDiscussion/Talk" pages. The idea is that people can use those talk pages to discuss or ask questions about a page. However, while people do add questions or ideas to these pages, very rarely will anyone respond to them or see their feedback. This feature has thus been disabled. Please use lists, IRC/Matrix or discussion discourse to ask questions about or discuss wiki pages. Thanks, kevin signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@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
wiki talk pages editing disabled
Greetings everyone. I've disabled editing of our mediawiki "iDiscussion/Talk" pages. The idea is that people can use those talk pages to discuss or ask questions about a page. However, while people do add questions or ideas to these pages, very rarely will anyone respond to them or see their feedback. This feature has thus been disabled. Please use lists, IRC/Matrix or discussion discourse to ask questions about or discuss wiki pages. Thanks, kevin signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [SONAME BUMP] jsoncpp 1.9.5
Am Mittwoch, dem 03.11.2021 um 20:10 +0100 schrieb Björn 'besser82' Esser: > Hi, > > jsoncpp 1.9.5 has just been released and it bumps its library soname > from 24 to 25. The following packages are affected: > > * cmake > * domoticz > * guayadeque > * libopenshot > * minetest > * notekit > * oomd > * openxr > * paraview > * pcl > * polybar > * qpid-proton > * raceintospace > * radiotray-ng > * torque > * vfrnav > * vtk > * waybar > > I'll take care of rebuilding in the `f36-build-side-47369` side-tag > for > all consumers myself, when updating jsoncpp, as it needs some > bootstrapping cycle for cmake. I forgot to mention * lgogdownloader The libopenshot package is not part of Fedora, it belongs to a third- party repo actually. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[Bug 2020025] New: perl-Spreadsheet-XLSX-0.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2020025 Bug ID: 2020025 Summary: perl-Spreadsheet-XLSX-0.17 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Spreadsheet-XLSX Keywords: FutureFeature, Triaged Assignee: redhat-bugzi...@linuxnetz.de Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, redhat-bugzi...@linuxnetz.de Target Milestone: --- Classification: Fedora Latest upstream release: 0.17 Current version/release in rawhide: 0.16-1.fc36 URL: https://metacpan.org/dist/Spreadsheet-XLSX Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8122/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020025 ___ 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
Re: [CoreOS] Fedora CoreOS Community Video Meeting 2021-11-02
Would you like to have this meeting uploaded to Fedora Project's YouTube channel? Br, Eduard Lucena El mié., 3 de noviembre de 2021 18:34, Dusty Mabe escribió: > > > On 11/2/21 10:19 PM, Dusty Mabe wrote: > > Hi All, > > > > Tomorrow we will be holding a video meeting for the Fedora CoreOS > community. > > > > Colin Walters will be presenting on a new proposal for "CoreOS Layering". > > https://github.com/coreos/enhancements/pull/7 > > > > We'll also be discussing any meeting tickets and possibly revisit our > list of high level > > issues. > > > > Time: 16:30 UTC (same as normal) on Wednesday October 6th > > Location: https://meet.google.com/igd-ekxw-nzi (will be recorded) > > Agenda/Notes: https://hackmd.io/5bdC2OLjQYmB5ErZ4AzpdA > > Thanks to everyone who attended! Here is a link to the meeting recording: > > > https://dustymabe.fedorapeople.org/meetings/2021-11-03_FCOS-Community-Meeting.mp4 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: [CoreOS] Fedora CoreOS Community Video Meeting 2021-11-02
On 11/2/21 10:19 PM, Dusty Mabe wrote: > Hi All, > > Tomorrow we will be holding a video meeting for the Fedora CoreOS community. > > Colin Walters will be presenting on a new proposal for "CoreOS Layering". > https://github.com/coreos/enhancements/pull/7 > > We'll also be discussing any meeting tickets and possibly revisit our list of > high level > issues. > > Time: 16:30 UTC (same as normal) on Wednesday October 6th > Location: https://meet.google.com/igd-ekxw-nzi (will be recorded) > Agenda/Notes: https://hackmd.io/5bdC2OLjQYmB5ErZ4AzpdA Thanks to everyone who attended! Here is a link to the meeting recording: https://dustymabe.fedorapeople.org/meetings/2021-11-03_FCOS-Community-Meeting.mp4 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Fedora 35 status and testing needed
On Mon, Oct 25, 2021 at 11:03 AM Jun Aruga wrote: > > On Mon, Oct 25, 2021 at 10:33 AM Samuel Sieb wrote: > > > > On 2021-10-25 01:21, Jun Aruga wrote: > > > I might find the issues about installation with the Fedora 35 64-bit > > > network install image. How and where can I report it? > > > Is the beta installation too old to test now? Thanks. > > > https://getfedora.org/en/workstation/download/ > > > > The test list (t...@lists.fedoraproject.org) is the place to discuss not > > yet released Fedora versions. Beta is too old. There should be RC > > images somewhere. > > OK. Thanks for the info. 4 days ago, before Fedora 35 final release, I tried Fedora 35 RC 1.2 installer. Then I saw one issue in the case that my Laptop has one 2 TB SSD and one 250 GB USB disk. As I couldn't find how to report this report, I wrote the issue with some images. Fedora 35 RC1.2 installer: “Not enough free space on selected disks.” on selecting 2 disks https://discussion.fedoraproject.org/t/34110 -- Jun | He - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[SONAME BUMP] jsoncpp 1.9.5
Hi, jsoncpp 1.9.5 has just been released and it bumps its library soname from 24 to 25. The following packages are affected: * cmake * domoticz * guayadeque * libopenshot * minetest * notekit * oomd * openxr * paraview * pcl * polybar * qpid-proton * raceintospace * radiotray-ng * torque * vfrnav * vtk * waybar I'll take care of rebuilding in the `f36-build-side-47369` side-tag for all consumers myself, when updating jsoncpp, as it needs some bootstrapping cycle for cmake. Thanks, Björn aka besser82 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: what is wrong with this conditional scriplet on rpm.spec
On Wed, 2021-11-03 at 14:26 -0400, Ben Beasley wrote:
> I don’t know where to find documentation for operator precedence in
> RPM
> conditional expressions, but it looks like “!” binds more tightly
> than
> “>=”, so
>
> > %if ! 0%{?rhel} >= 8
>
> is grouped as
>
> > %if (! 0%{?rhel}) >= 8
>
> which becomes, on Fedora:
>
> > %if (! 00) >= 8
>
> > %if 1 >= 8
>
> and therefore evaluates false.
>
> Writing
>
> > %if ! (0%{?rhel} >= 8)
>
> seems to do what you want, as would:
yes is exactly what I'm missing
Thank you
> > %if 0%{?rhel} < 8
>
the logic doesn't fail , but it is trick because includes {?fedora}
> On 11/3/21 14:09, Sérgio Basto wrote:
> > Hi,
> >
> > I just notice build in mock or koji this scriptlet [1] on a build
> > for
> > Fedora gives me "is rhel 8 or 9" , what I'm missing ?
> >
> >
> > Thank you
> >
> > [1]
> > %if ! 0%{?rhel} >= 8
> > echo "is not rhel >= 8"
> > %else
> > echo "is rhel 8 or 9"
> > %endif
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: what is wrong with this conditional scriplet on rpm.spec
I don’t know where to find documentation for operator precedence in RPM
conditional expressions, but it looks like “!” binds more tightly than
“>=”, so
> %if ! 0%{?rhel} >= 8
is grouped as
> %if (! 0%{?rhel}) >= 8
which becomes, on Fedora:
> %if (! 00) >= 8
> %if 1 >= 8
and therefore evaluates false.
Writing
> %if ! (0%{?rhel} >= 8)
seems to do what you want, as would:
> %if 0%{?rhel} < 8
On 11/3/21 14:09, Sérgio Basto wrote:
Hi,
I just notice build in mock or koji this scriptlet [1] on a build for
Fedora gives me "is rhel 8 or 9" , what I'm missing ?
Thank you
[1]
%if ! 0%{?rhel} >= 8
echo "is not rhel >= 8"
%else
echo "is rhel 8 or 9"
%endif
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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
what is wrong with this conditional scriplet on rpm.spec
Hi,
I just notice build in mock or koji this scriptlet [1] on a build for
Fedora gives me "is rhel 8 or 9" , what I'm missing ?
Thank you
[1]
%if ! 0%{?rhel} >= 8
echo "is not rhel >= 8"
%else
echo "is rhel 8 or 9"
%endif
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
c4core 0.1.7 coming to Rawhide in one week (soname bump)
On 2021-11-10, or slightly later, I will build c4core 0.1.7 in Rawhide. This includes an soname bump. This notice is just a formality since c4core was introduced in order to package rapidyaml in the future, and no packages yet depend on it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, Nov 03, 2021 at 01:31:50PM -0400, Steve Grubb wrote:
> Hello,
>
> On Wednesday, November 3, 2021 10:00:05 AM EDT David Sastre wrote:
> > I assume that the people who worked on it looked into various different
> > possibilities for its implementation and decide on the current one, but I
> > have a few questions:
> >
> >- Since there are people concerned about the increased size of the
> >binary, and since none of the fields are mandatory, would it be
> > beneficial to use a package URL (PURL[1]) instead? That way, a few bytes
> > can be saved (a few values are included in the same key).
> >
> > E.g.
> >
> > {
> > "type":"rpm",
> > "os":"fedora",
> > "osVersion":"33",
> > "name":"coreutils",
> > "version":"4711.0815.fc13",
> > "architecture":"arm32",
> > "osCpe": "cpe:/o:fedoraproject:fedora:33",
> > "debugInfoUrl": "https://debuginfod.fedoraproject.org/"}
>
> I keep seeing mention of architecture in this discussion. Isn't arch
> available as the e_machine member of the elf header?
It is, but we include in the header for completeness, so that the
header is "self-contained" so to speak. (Also, at least in priciple
it's be possible for the code arch to not match the package architecture,
like when you purposefully build a 32bit binary in 64-bit rpm…)
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
Hello,
On Wednesday, November 3, 2021 10:00:05 AM EDT David Sastre wrote:
> I assume that the people who worked on it looked into various different
> possibilities for its implementation and decide on the current one, but I
> have a few questions:
>
>- Since there are people concerned about the increased size of the
>binary, and since none of the fields are mandatory, would it be
> beneficial to use a package URL (PURL[1]) instead? That way, a few bytes
> can be saved (a few values are included in the same key).
>
> E.g.
>
> {
> "type":"rpm",
> "os":"fedora",
> "osVersion":"33",
> "name":"coreutils",
> "version":"4711.0815.fc13",
> "architecture":"arm32",
> "osCpe": "cpe:/o:fedoraproject:fedora:33",
> "debugInfoUrl": "https://debuginfod.fedoraproject.org/"}
I keep seeing mention of architecture in this discussion. Isn't arch
available as the e_machine member of the elf header?
Cheers,
-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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: [HEADS UP] ImageMagick-6.9.12.28
On Wed, 2021-11-03 at 23:43 +0900, Mamoru TASAKA wrote:
> Sérgio Basto wrote on 2021/11/03 0:59:
> > Please build your packages for F35 in f35-build-side-47231
> >
> > or maybe we should request help of an proven packager
> >
> > Thank you
> >
> >
> >
> > On Sun, 2021-10-31 at 22:02 +, Sérgio Basto wrote:
> > > On Sun, 2021-10-31 at 22:56 +0100, Fabio Valentini wrote:
> > > > On Sun, Oct 31, 2021 at 10:44 PM Luya Tshimbalanga
> > > > wrote:
> > > > >
> > > > > Hello team,
> > > > >
> > > > > ImageMagick is updated 6.9.12.28 on Rawhide and got side tag as
> > > > > 35-build-side-47231.
> > > >
> > > > Sorry, I am confused. Did you mean to say the update and rebuilds
> > > > for
> > > > rawhide are *finished* and you're starting the process for f35
> > > > now?
> > >
> > > yes, we are asking to build all packages for F35 in f35-build-side-
> > > 47231
> > >
> > > I did it for dvdauthor
> > >
> > > cd ../dvdauthor
> > > git pull
> > > git checkout f35
> > > git merge rawhide
> > > git push
> > > fedpkg build --target=f35-build-side-47231
> > >
> > > Thank you
> > >
> > > > Otherwise, the side tag name does not match "updated [...] on
> > > > Rawhide
> > > > and got side tag as [f]35-build-side-x".
> > > >
> > > > > For my understanding, the following packages
> > > > > (including those from RPM Fusion) may need a rebuild based on
> > > > > these
> > > > > dependencies:
> > > > >
> > > > > `dnf repoquery --whatrequires "libMagick*" --qf "%{reponame}
> > > > > %{sourcerpm}" -q | sed 's/updates/fedora/' | pkgname | sort -u`
> > > > >
> > > > > fedora autotrace
> > > > > fedora chafa
> > > > > fedora converseen
> > > > > fedora digikam
> > > > > fedora dmtx-utils
> > > > > fedora dvdauthor
> > > > > fedora eom
> > > > > fedora ImageMagick
> > > > > fedora kxstitch
> > > > > fedora pfstools
> > > > > fedora php-pecl-imagick
> > > > > fedora psiconv
> > > > > fedora q
> > > > > fedora R-magick
> > > > > fedora rss-glx
> > > > > fedora rubygem-rmagick
> > > > > fedora synfig
> > > > > fedora synfigstudio
> > > > > fedora vdr-scraper2vdr
> > > > > fedora vdr-skinelchihd
> > > > > fedora vdr-skinnopacity
> > > > > fedora vdr-tvguide
> > > > > fedora vips
> > > > > fedora WindowMaker
> > > > > rpmfusion-free libopenshot
> > > > > rpmfusion-free xine-lib
> > > > >
> > > > > Please use f35-build-side-47231 side-tag to build your package,
> > > > > and
> > > > > I
> > > > > (or my co-maintainer) am intending to merge in F35 repository
> > > > > in
> > > > > about a
> > > > > week.
> > > >
> > > > Given that Fedora 35 is now officially *stable*, and ImageMagick
> > > > not
> > > > being a leaf package, such a disruptive update would require
> > > > FESCo
> > > > exception to the Updates Policy.
> > > > If you want to file a ticket for such an exception, it would be
> > > > great
> > > > if people could verify that this is actually the *complete* list
> > > > of
> > > > packages that need to be rebuilt (and that they indeed *can* be
> > > > rebuilt without issues on F35), so that there is no negative
> > > > fallout
> > > > from broken dependencies on a stable release.
> > > >
> > > > Fabio
>
> All the above packages on Fedora are now rebuilt:
>
> for f in ImageMagick-libs ImageMagick-c++ ; do dnf repoquery --quiet
> --repo=koji-35-build-side-47231 --qf '%{sourcerpm}' --whatrequires $f ;
> done | sort -f | uniq | cat -n
> 1 autotrace-0.31.1-62.fc35.src.rpm
> 2 chafa-1.2.1-6.fc35.src.rpm
> 3 converseen-0.9.9.2-2.fc35.src.rpm
> 4 digikam-7.3.0-2.fc35.src.rpm
> 5 dmtx-utils-0.7.6-9.fc35.1.src.rpm
> 6 dvdauthor-0.7.2-16.fc35.src.rpm
> 7 eom-1.26.0-2.fc35.src.rpm
> 8 ImageMagick-6.9.12.28-1.fc35.src.rpm
> 9 kxstitch-2.1.1-6.fc35.src.rpm
> 10 php-pecl-imagick-3.5.1-2.fc35.src.rpm
> 11 psiconv-0.9.8-36.fc35.src.rpm
> 12 q-7.11-44.fc35.src.rpm
> 13 R-magick-2.7.3-2.fc35.src.rpm
> 14 rss-glx-0.9.1.p-50.fc35.src.rpm
> 15 rubygem-rmagick-4.2.3-3.fc35.src.rpm
> 16 synfig-1.4.0-4.fc35.src.rpm
> 17 synfigstudio-1.4.0-3.fc35.src.rpm
> 18 vdr-scraper2vdr-1.0.11-14.20190128gitd9f6cb4.fc35.1.src.rpm
> 19 vdr-skinelchihd-0.5.0-7.fc35.src.rpm
> 20 vdr-skinnopacity-1.1.8-3.fc35.src.rpm
> 21 vdr-tvguide-1.3.5-3.fc35.src.rpm
> 22 vips-8.11.3-6.fc35.src.rpm
> 23 WindowMaker-0.95.9-7.fc35.src.rpm
>
> and also pfstools-2.1.0-21.fc35 is rebuilt.
>
>
> https://koji.fedoraproject.org/koji/builds?inherited=0=47231=-completion_time=1
>
Many thanks , side-tag submit to testing in bodhi
https://bodhi.fedoraproject.org/updates/FEDORA-2021-df1fa3d3e0
> Regards,
> Mamoru
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
>
[Bug 1972092] perl-WebService-Dropbox-2.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1972092 Miro Hrončok changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |CLOSED Last Closed||2021-11-03 16:52:26 --- Comment #3 from Miro Hrončok --- Automation has figured out the package is retired in rawhide. If you like it to be unretired, please open a ticket at https://pagure.io/releng/new_issue?template=package_unretirement -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1972092 ___ 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
Re: Fedora 35 security update of curl blocked for a month
On Wed, 2021-11-03 at 08:54 +0100, Kamil Dudka wrote: > On Tuesday, November 2, 2021 6:32:34 PM CET Adam Williamson wrote: > > 4. The email notifications should be customizable via > > https://apps.fedoraproject.org/notifications/ , I believe. I do agree > > it would be good if we could tweak some defaults in the notification > > code to not notify you when you do things to your own stuff, as you > > likely don't need a notification in that case. But I never get around > > to doing this for my own account, let alone sending a patch to make it > > better for everyone... > > To be clear, the problem is not that I get notifications for my own actions. > I prefer to get such notifications on services like Github or Bugzilla, so > that the full story is recorded in my mailbox. > > The actual problem was that I received the same e-mail 49 times This is because, although you clicked the button once, it submitted 49 separate waivers. That's arguably more Bodhi's fault than the notification system's; it should maybe be smart enough to assume you only want to waive *failed* tests, not waive every single test that was run on the update. > and that its > subject nor the body contained any information besides the (currently valid) > URL to some JSON data. I don't recall exactly how this part works, but it's *probably* because this is broken: https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/blob/develop/fedmsg_meta_fedora_infrastructure/waiverdb.py#L33-L36 note it tries to use the key 'result_id' from the message, but current waiverdb.waiver.new messages do not seem to include that field. This is also why, when you look up waiverdb messages on datagrepper: https://apps.fedoraproject.org/datagrepper/raw?category=waiverdb=172800 they don't have a little summary after 'JSON' like messages whose metadata processor works do (that summary is this same 'subtitle' thing from the metadata processor). I would guess that the notification system wants to use that subtitle either as the mail subject or in the body or both, but because it's broken, it falls back on just "fedmsg notification". I'll send a patch to fix that. Of course, what we're *really* behind on here is getting datagrepper and FMN rewritten to use fedora-messaging and message schemas[0] instead of fedmsg and the fedmsg_meta stuff... [0] https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Timeshift maintainer
I would like to ping srakitnican, the Timeshift maintainer (someone is in touch with them?). Timeshift is a graphical tool to manage BTRFS snapshots. I don't use it personally, but I know a bunch of people that rely on it. Thimeshift coming from the Fedora repository, doesn't work on Fedora Linux 35, due to a change in lsblk (util-linux). Upstream released a patch this summer. Upstream version is 21.09.1, while the version in the Fedora repository is 20.03 There are various open bugs on Bugzilla related to this package. Someone has built a COPR repository [1] with the latest upstream release. In such repository it is stated: "Here are compiled newest timeshift from Github for temporary update until timeshift on the main fedora repository get updated by the package maintener. This version intended to fix timeshift bugs on Fedora 35 Workstation." [1] http://copr.fedorainfracloud.org/coprs/oprizal/timeshift-upstream/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Mi, 03.11.21 15:00, David Sastre (d.sastre.med...@gmail.com) wrote: >- There are a few existing formats for software identification and SBOMs: > - SPDX[2], used in the example spec in the proposal > - SWID tags[3][4] > - OWASP CycloneDX[5] > - CPE[6], used in the example JSON above > - PURL[1] > - probably more :D I was aware of some of these, in particular CPE. One of our goals here is to encode data in the most obvious way though, i.e. stay as close to what the native package manager of the distro does and how it names things, as we can, to make things easy and mapped directy and not needlessly pile specs on top of specs. i.e. the goal is not "decoration" if you so will but directly usable fields whose data you can pass immediately to the package management tools and they do useful stuff. I think some of the listed specs are fine (and I think it might even make sense to make dnf understand them natively, in select cases), but I am not convinced we should mandate them here, since our spec is intentionally simple and liberal in the field it contains: it should be up to the distro to figure out precisely the fields they want to populate, we just describe a small set of recommended fields and their values, in the most obvious way. (There's also the problem of chicken and egg: I think only two of the specs you listed gained supported outside of their respective niches, i.e. the SPDX stuff for licensing and the CPE stuff for marking OS versions. I doubt that this ELF spec is the right place to push them more widely, this ELF spec is too nichey for that in itself. Of course the fact that those specs are not widely used isn't improved by not using it here either, but I don't think this is the job of our ELF spec, if you follow what I mean.) So, the way I see it, the fact we use JSON makes it easy to add additional fields later. We'd welcome a PR to our spec that declares additional, optional fields for the more relevant specs you listed above. i.e. we are happy to extend the table at the end of: https://systemd.io/COREDUMP_PACKAGE_METADATA/ with more stuff. File a patch adding that here: https://github.com/systemd/systemd/pulls Once you got these field is into the upstream spec, the next step would be to convince the distros to actually populate the fields though, but I think that should happen independently of our current fedora ELF feature. And it should probably not only entail that these fields are included in the coredumpable metadata, but probably also that the distro package management tools can parse/generate them natively. In fact that's probably the priority, the coredumpable part should be secondary to that. > [3]: http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd broken link. > [4]: > https://csrc.nist.gov/schema/swid/2015-extensions/swid-2015-extensions-1.0.xsd broken link. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [HEADS UP] ImageMagick-6.9.12.28
Sérgio Basto wrote on 2021/11/03 0:59:
Please build your packages for F35 in f35-build-side-47231
or maybe we should request help of an proven packager
Thank you
On Sun, 2021-10-31 at 22:02 +, Sérgio Basto wrote:
On Sun, 2021-10-31 at 22:56 +0100, Fabio Valentini wrote:
On Sun, Oct 31, 2021 at 10:44 PM Luya Tshimbalanga
wrote:
Hello team,
ImageMagick is updated 6.9.12.28 on Rawhide and got side tag as
35-build-side-47231.
Sorry, I am confused. Did you mean to say the update and rebuilds for
rawhide are *finished* and you're starting the process for f35 now?
yes, we are asking to build all packages for F35 in f35-build-side-
47231
I did it for dvdauthor
cd ../dvdauthor
git pull
git checkout f35
git merge rawhide
git push
fedpkg build --target=f35-build-side-47231
Thank you
Otherwise, the side tag name does not match "updated [...] on Rawhide
and got side tag as [f]35-build-side-x".
For my understanding, the following packages
(including those from RPM Fusion) may need a rebuild based on these
dependencies:
`dnf repoquery --whatrequires "libMagick*" --qf "%{reponame}
%{sourcerpm}" -q | sed 's/updates/fedora/' | pkgname | sort -u`
fedora autotrace
fedora chafa
fedora converseen
fedora digikam
fedora dmtx-utils
fedora dvdauthor
fedora eom
fedora ImageMagick
fedora kxstitch
fedora pfstools
fedora php-pecl-imagick
fedora psiconv
fedora q
fedora R-magick
fedora rss-glx
fedora rubygem-rmagick
fedora synfig
fedora synfigstudio
fedora vdr-scraper2vdr
fedora vdr-skinelchihd
fedora vdr-skinnopacity
fedora vdr-tvguide
fedora vips
fedora WindowMaker
rpmfusion-free libopenshot
rpmfusion-free xine-lib
Please use f35-build-side-47231 side-tag to build your package, and
I
(or my co-maintainer) am intending to merge in F35 repository in
about a
week.
Given that Fedora 35 is now officially *stable*, and ImageMagick not
being a leaf package, such a disruptive update would require FESCo
exception to the Updates Policy.
If you want to file a ticket for such an exception, it would be great
if people could verify that this is actually the *complete* list of
packages that need to be rebuilt (and that they indeed *can* be
rebuilt without issues on F35), so that there is no negative fallout
from broken dependencies on a stable release.
Fabio
All the above packages on Fedora are now rebuilt:
for f in ImageMagick-libs ImageMagick-c++ ; do dnf repoquery --quiet
--repo=koji-35-build-side-47231 --qf '%{sourcerpm}' --whatrequires $f ; done |
sort -f | uniq | cat -n
1 autotrace-0.31.1-62.fc35.src.rpm
2 chafa-1.2.1-6.fc35.src.rpm
3 converseen-0.9.9.2-2.fc35.src.rpm
4 digikam-7.3.0-2.fc35.src.rpm
5 dmtx-utils-0.7.6-9.fc35.1.src.rpm
6 dvdauthor-0.7.2-16.fc35.src.rpm
7 eom-1.26.0-2.fc35.src.rpm
8 ImageMagick-6.9.12.28-1.fc35.src.rpm
9 kxstitch-2.1.1-6.fc35.src.rpm
10 php-pecl-imagick-3.5.1-2.fc35.src.rpm
11 psiconv-0.9.8-36.fc35.src.rpm
12 q-7.11-44.fc35.src.rpm
13 R-magick-2.7.3-2.fc35.src.rpm
14 rss-glx-0.9.1.p-50.fc35.src.rpm
15 rubygem-rmagick-4.2.3-3.fc35.src.rpm
16 synfig-1.4.0-4.fc35.src.rpm
17 synfigstudio-1.4.0-3.fc35.src.rpm
18 vdr-scraper2vdr-1.0.11-14.20190128gitd9f6cb4.fc35.1.src.rpm
19 vdr-skinelchihd-0.5.0-7.fc35.src.rpm
20 vdr-skinnopacity-1.1.8-3.fc35.src.rpm
21 vdr-tvguide-1.3.5-3.fc35.src.rpm
22 vips-8.11.3-6.fc35.src.rpm
23 WindowMaker-0.95.9-7.fc35.src.rpm
and also pfstools-2.1.0-21.fc35 is rebuilt.
https://koji.fedoraproject.org/koji/builds?inherited=0=47231=-completion_time=1
Regards,
Mamoru
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20211103.n.0 compose check report
No missing expected images. Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 6/206 (x86_64), 6/141 (aarch64) New failures (same test not failed in Fedora-Rawhide-20211101.n.0): ID: 1050204 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/1050204 ID: 1050207 Test: x86_64 Server-dvd-iso install_resize_lvm URL: https://openqa.fedoraproject.org/tests/1050207 ID: 1050223 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/1050223 ID: 1050271 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1050271 ID: 1050362 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/1050362 ID: 1050374 Test: aarch64 Server-dvd-iso install_repository_nfs_variation@uefi URL: https://openqa.fedoraproject.org/tests/1050374 ID: 1050421 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1050421 ID: 1050491 Test: aarch64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/1050491 ID: 1050538 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1050538 Old failures (same test failed in Fedora-Rawhide-20211101.n.0): ID: 1050290 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1050290 ID: 1050378 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1050378 ID: 1050393 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1050393 Soft failed openQA tests: 3/206 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20211101.n.0): ID: 1050310 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1050310 ID: 1050311 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1050311 ID: 1050316 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1050316 ID: 1050389 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1050389 ID: 1050406 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1050406 Passed openQA tests: 132/141 (aarch64), 197/206 (x86_64) New passes (same test not passed in Fedora-Rawhide-20211101.n.0): ID: 1050404 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1050404 ID: 1050435 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/1050435 ID: 1050495 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1050495 ID: 1050500 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1050500 ID: 1050504 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1050504 ID: 1050534 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1050534 Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: Used mem changed from 235 MiB to 200 MiB Previous test data: https://openqa.fedoraproject.org/tests/1047953#downloads Current test data: https://openqa.fedoraproject.org/tests/1050202#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: Used mem changed from 238 MiB to 210 MiB Previous test data: https://openqa.fedoraproject.org/tests/1047967#downloads Current test data: https://openqa.fedoraproject.org/tests/1050216#downloads Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.17 to 0.42 Previous test data: https://openqa.fedoraproject.org/tests/1048003#downloads Current test data: https://openqa.fedoraproject.org/tests/1050252#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 7 MiB to 4 MiB Average CPU usage changed from 25.31428571 to 9.08095238 Previous test data: https://openqa.fedoraproject.org/tests/1048006#downloads Current test data: https://openqa.fedoraproject.org/tests/1050255#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 9 MiB to 4 MiB System load changed from 0.98 to 0.59 Previous test data: https://openqa.fedoraproject.org/tests/1048019#downloads Current test data: https://openqa.fedoraproject.org/tests/1050268#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: 1 packages(s) added since
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
This is an interesting proposal and discussion.
I assume that the people who worked on it looked into various different
possibilities for its implementation and decide on the current one, but I
have a few questions:
- Since there are people concerned about the increased size of the
binary, and since none of the fields are mandatory, would it be beneficial
to use a package URL (PURL[1]) instead? That way, a few bytes can be saved
(a few values are included in the same key).
E.g.
{
"type":"rpm",
"os":"fedora",
"osVersion":"33",
"name":"coreutils",
"version":"4711.0815.fc13",
"architecture":"arm32",
"osCpe": "cpe:/o:fedoraproject:fedora:33",
"debugInfoUrl": "https://debuginfod.fedoraproject.org/"}
would become:
{
"purl":"pkg:rpm/fedora/coreutils@4711.0815.fc13?arch=arm32=fedora-13",
"osCpe": "cpe:/o:fedoraproject:fedora:33",
"debugInfoUrl": "https://debuginfod.fedoraproject.org/"}
- There are a few existing formats for software identification and SBOMs:
- SPDX[2], used in the example spec in the proposal
- SWID tags[3][4]
- OWASP CycloneDX[5]
- CPE[6], used in the example JSON above
- PURL[1]
- probably more :D
a few of those are too verbose to be considered, but in particular
CycloneDX can be expressed in JSON and supports PURL
- What level of trustworthiness would the generated JSON have? Is it
relevant or in scope? Some of the existing formats support signatures, e.g.
CycloneDX supports JSF[7].
Thanks!
[1]: https://github.com/package-url/purl-spec
[2]: https://spdx.github.io/spdx-spec/
[3]: http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd
[4]:
https://csrc.nist.gov/schema/swid/2015-extensions/swid-2015-extensions-1.0.xsd
[5]: https://cyclonedx.org/docs/1.3/json/#components
[6]:
https://csrc.nist.gov/projects/security-content-automation-protocol/specifications/cpe
[7]: https://cyberphone.github.io/doc/security/jsf.html
On Mon, Oct 25, 2021 at 9:09 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
>
> == Summary ==
> All binaries (executables and shared libraries) are annotated with an
> ELF note that identifies the rpm for which this file was built. This
> allows binaries to be identified when they are distributed without any
> of the rpm metadata. `systemd-coredump` uses this to log package
> versions when reporting crashes.
>
> == Owner ==
> * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
> * Email: zbys...@in.waw.pl
> * Name: Lennart Poettering
> * Email: mzsrq...@0pointer.net
>
>
> == Detailed Description ==
> People mix binaries (programs and libraries) from different
> distributions (for example using Fedora containers on Debian or vice
> versa), and distribute binaries without packaging metadata (for
> example by stripping everything except the binary from a container
> image, also removing `/usr/lib/.build-id/*`), compile their own rpm
> packages (for internal distribution and installation), and compile and
> distribute their own binaries. Sometimes we need to introspect a
> binary and figure out its provenance, for example when a program
> crashes and we are looking at a core dump, but also when we have a
> binary without the packaging metadata. When the need to introspect a
> binary arises, we have some very good mechanisms to show the
> provenance: when a file is installed through the package manager we
> can directly list the providing package, but even without this we can
> use build-ids embedded in the binary to uniquely identify the
> originating build. But those mechanisms work best when we're in the
> realm of a single distribution. In particular, build-ids can be easily
> tied to a source rpm, but only when we have the source rpm is part of
> the distribution and the build-id was registered in the appropriate
> database which maps build-ids to real package names. When we move
> outside of the realm of a single distribution, it can be hard to
> figure out where a given binary originates from. If we know that a
> binary is from a given distribution, we may be able to use some
> distro-specific mechanism to figure out this information. But those
> mechanisms will be different for different distributions and will
> often require network access. With this change we aim to provide a
> mechanism that is is very simple, provides a "human-readable" origin
> information without further processing, is portable across distros,
> and works without network access.
>
> The directly motivating use case is display of core dumps. Right now
> we have build-ids, but those are just opaque hexadecimal numbers that
> are not meaningful to users. We would like to immediately list
> versions of packages involved in the crash (including both the program
> and any libraries it links to). It is not enough to query the rpm
> database to do the equivalent of `rpm -qf …`: very often programs
> crash after some packages have
Re: Announcing LLVM Snapshot Packages for Fedora Linux
On Wed, Nov 3, 2021 at 9:47 AM Jonathan Wakely wrote: > > > > On Fri, 8 Oct 2021 at 11:15, Konrad Kleine wrote: >> >> Dear Fedora packagers, developers and users, >> >> we have some good news for you: >> >> We are beginning to build nightly snapshot packages of LLVM for the latest >> versions of Fedora Linux (currently 34, 35 and rawhide) for a growing list of >> architectures. >> >> You can grab them here: >> >> https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/ >> > > Nice to see this going public, I will definitely be using it, thanks! > > And I'll shamelessly plug my copr with weekly GCC snapshots ;-) > https://copr.fedorainfracloud.org/coprs/jwakely/gcc-latest/ > Maybe this is worth a commblog or magazine post? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing LLVM Snapshot Packages for Fedora Linux
On Fri, 8 Oct 2021 at 11:15, Konrad Kleine wrote: > Dear Fedora packagers, developers and users, > > we have some good news for you: > > We are beginning to build nightly snapshot packages of LLVM for the latest > versions of Fedora Linux (currently 34, 35 and rawhide) for a growing list > of > architectures. > > You can grab them here: > > https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/ > > Nice to see this going public, I will definitely be using it, thanks! And I'll shamelessly plug my copr with weekly GCC snapshots ;-) https://copr.fedorainfracloud.org/coprs/jwakely/gcc-latest/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Election Interview Questions — FESCo (F35)
Hi, this is the season: we have the chance to update questions for the interviews. Any stuff that you think the candidates should answer in particular? If there is no input, I expect that the questions will be unchanged (see below). This might not be a bad thing, because they are open-ended and anyway candidates can write stuff not in reply to a question. But if there is something particular you'd like to see answered, it would be good to mention it. Zbyszek - Forwarded message from Ben Cotton - In order to move forward with the next election, we need to determine which mandatory questions FESCo would like to have asked of candidates. We need FESCo to please identify the questions before 2021-11-17 so we can properly communicate them to candidates and so they enough time to answer them. In case the selection is not complete by 17 November, the Election wrangler will use the same set of questions as the last election cycle: * Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora? * How do you currently contribute to Fedora? How does that contribution benefit the community? * How should we handle cases where Fedora's and Red Hat Enterprise Linux's needs conflict in an incompatible way? * What else should community members know about you or your positions? Some additional questions are listed in the [wiki](https://fedoraproject.org/wiki/Elections/Questionnaire#FESCo_.28Engineering.29), or you may come up with new ones. -- https://pagure.io/fesco/issue/2688 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Woah! [Thanks, Nest sponsors]
Sorry everyone, I wanted to send a private email :( -- Tomasz Torcz 72->| 80->| to...@pipebreaker.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Woah! [Thanks, Nest sponsors]
On Wed, Oct 13, 2021 at 02:33:19PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 13 October 2021 at 13:08, Luna Jernberg wrote: > > You had to register at a website during the event, > > That I did. On August 7th, I received an e-mail with a promo code to > enter at https://coolstuff.redhat.com/promo/fedora which I did, but I > haven't heard from them since. > > > got an email with > > tracking information from both Fedex and Red Hat > > Nothing yet. :( Cześć Dominik, Czy Ty masz adres korespondencyjny w Polsce (o ile opsec pozwala Ci zdradzić ;)? Mój swag-pack został wysłany i dostałem od Fedex dokumentu do odprawy celnej… też tak miałeś? -- Tomasz Torcz 72->| 80->| to...@pipebreaker.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
FESCo election nominations are now open
Now through 17 November, you may nominate candidates for the open seat on the Fedora Engineering Steering Committee. To nominate yourself (or others, if you check with them first), visit: https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations FESCo is currently selecting the questions for the interview questionnaire, which will be finalized before the beginning of the interview period. For more information, see the Community Blog post: https://communityblog.fedoraproject.org/f35-elections-nominations-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@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
FESCo election nominations are now open
Now through 17 November, you may nominate candidates for the open seat on the Fedora Engineering Steering Committee. To nominate yourself (or others, if you check with them first), visit: https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations FESCo is currently selecting the questions for the interview questionnaire, which will be finalized before the beginning of the interview period. For more information, see the Community Blog post: https://communityblog.fedoraproject.org/f35-elections-nominations-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: protobuf 3.18.1 update coming to rawhide
> I already announced another protobuf 3.19.0 update and rebuild and on > top of it there is PR open to enable the Java bindings again: Great, thanks. Zuzana. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[Test-Announce] Fedora 36 Rawhide 20211103.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 36 Rawhide 20211103.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/36 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211103.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211103.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211103.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211103.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211103.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211103.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211103.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@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: protobuf 3.18.1 update coming to rawhide
On Tue, Nov 02, 2021 at 03:11:00PM +0100, Zuzana Miklankova wrote: > Sorry for the late reply, but I noticed this change only when the rebuild > of mysql-connector-java failed. > > > Because of missing dependencies we had to disable the Java bindings > > which breaks the build of: > > mysql-connector-java has a protobuf-java BuildRequires, so unfortunately > is not buildable in current rawhide (the dependency is quite big). > Could I please just ask, what were the specific reasons for removing java > bindings from protobuf - what dependencies are problematic? Is dropping > of java support inevitable? We had to disable the Java bindings because of missing dependencies. I already announced another protobuf 3.19.0 update and rebuild and on top of it there is PR open to enable the Java bindings again: https://src.fedoraproject.org/rpms/protobuf/pull-request/8 So maybe mysql-connector-java can be rebuild again once the above PR has been merged. Adrian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, Nov 3, 2021 at 9:41 AM Petr Pisar wrote: > > V Wed, Nov 03, 2021 at 01:45:00AM +0100, Miroslav Suchý napsal(a): > > Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a): > > > === Why not just use the rpm database? === > > > > > > > > > 17:34:33 The main reason for this appears to be that we > > > need the RPM db locally to resolve build-ids to package names. But > > > since containers wipe /var/lib/rpm, we can't do that. So the solution > > > is to put the ''nevra'' in ELF metadata? > > > 17:34:39 That feels like the wrong approach. > > > > > > > > > First, there are legitimate reasons to strip packaging metadata from > > > images. For example, for an initrd image from rpms, I get 117 MB of > > > files (without compression), and out of this `/var/lib/rpm` is 5.9 MB, > > > and `/var/lib/dnf` is 4.2 MB. This is an overhead of 9%. This is ''not > > > much'', but still too much to keep in the image unless necessary. > > > Similar ratios will happen for containers of similar size. Reducing > > > image size by one tenth is important. There is no `rpm` or `dnf` in > > > the image, to the package database is not even usable without external > > > tools. > > > > Devil advocate here: > > > > **Some** people wipe `/var/lib/rpm` to save 5.9 MB. And because of this we > > will put another 5.9 MB [citation needed] as metadata split across various > > ELF objects for **everybody**. > > > > When someone want really tiny image, I will expect they will start stipping > > ELF objects when they discover this feature. > > > Morover it only pertains ELF. What about other files? E.g. compiled Java > classes, or minified JavaScript libriaries? I will be proposing a separate system-wide F36 change for embedding package NVR inside Java JAR files iff the ELF change is accepted. -- Mikolaj Izdebski > > What about storing the RPM package identifier by a package manager when > installing a file into an extedned attribute of the file? That > would track origin of all files and users not intersted in the tracking > could easily remove the data. Effectively it would become a feature of the > package manager. Not of a build system. > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam 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
Fedora-Cloud-34-20211103.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211102.0): ID: 1050014 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1050014 ID: 1050015 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1050015 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
ocaml-* (was: Re: Orphaned packages looking for new maintainers)
On Mon, Oct 25, 2021 at 12:41:59PM +0200, Miro Hrončok wrote: > ocaml-charinfo-width orphan 2 weeks ago > ocaml-cmdlinerorphan 2 weeks ago > ocaml-cudforphan 2 weeks ago > ocaml-lambda-term avsej, orphan2 weeks ago > ocaml-lwt-log orphan 2 weeks ago > ocaml-mmaporphan 2 weeks ago > ocaml-ocplib-endian orphan 2 weeks ago > ocaml-result andyli, orphan, rjones 2 weeks ago > ocaml-zed orphan 2 weeks ago I took all of these, co-maintainers would be very welcome. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Fedora 36 System-Wide Change: java-17-openjdk as system JDK in F36 pre-announcement
On Mon, Nov 1, 2021 at 11:07 AM Jiri Vanek wrote: > > Hello! > > For wide hearing/reading, before final announcement, > https://fedoraproject.org/wiki/Changes/Java17 have anybody any opinion or > anything to say for/against? I am for this change. Fedora should use the latest OpenJDK by default. Required tooling changes (javapackages-tools etc.) that are needed to build packages with OpenJDK 17 are ready to be pushed once the change is accepted. All my packages (Maven, Ant and their dependencies) were already ported to Java 17, more info on java-devel list. -- Mikolaj > > > Happy Hacking, > J. > > > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
Fedora-Cloud-35-20211103.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20211102.0): ID: 1049998 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1049998 ID: 104 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/104 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Maíra Canal
On Tue, 2021-11-02 at 19:35 +, Maíra Canal via devel wrote: > Hello, > > I'm an undergrad student of Computer Engineering in Brazil. I use > Fedora for about a year as my only OS and I love the philosophy (and > the performance) of Fedora. Currently, I'm looking forward to being a > part of the community and contributing by supporting packages and > developing. I have already some experience contributing to the Linux > kernel, but I would like to contribute to Fedora directly. > > I'm looking for suggestions of applications to be packaged, so if you > have any, I'm glad to know. > > Looking forward to future cooperation, > Maíra Bom dia and Welcome! Picking up on what Zbyszek mentioned, another way to get started with packaging itself could be help review already open requests. You find a list of open review requests here: [1] and here are the docs on how to review: [2]. Maybe you find something that interests you. Hmm, as for the Fedora kernel: [3] Explains a bit what Fedora ARK [4] is and more recent developments. There are lots of different ways to get into the project. You can change and improve a lot of things. Including the docs :) [5]. BK [1]: https://fedoraproject.org/PackageReviewStatus/ [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ [3]: In the Fedora Project YouTube channel, Justin Forbes with newest changes with the Fedora kernel https://youtu.be/urUktTIP0Fs [4]: https://cki-project.gitlab.io/kernel-ark/ [5]: https://pagure.io/projects/fedora-docs/%2A ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, Nov 03, 2021 at 09:39:28AM +0100, Petr Pisar wrote: > > Devil advocate here: > > > > **Some** people wipe `/var/lib/rpm` to save 5.9 MB. And because of this we > > will put another 5.9 MB [citation needed] as metadata split across various > > ELF objects for **everybody**. This was already answered before, but since the thread is long, I'll repeat it: if you have 5.9 MB in /var/lib/rpm, this means that you have just a handful of packages, so the overhead of the ELF metadata would be *much* less than 5.9 MB. The overheads scale ~linearly with the number of files/packages, and you're now comparing a measurement for a minimal installation (the example was about an initrd!) with a measurement for a full-throated installation (3 ELF files!). > > When someone want really tiny image, I will expect they will start stipping > > ELF objects when they discover this feature. > > > Morover it only pertains ELF. What about other files? E.g. compiled Java > classes, or minified JavaScript libriaries? Those don't crash ;) so they are outside of the scope of interest of systemd-coredump. But FWIW, I think it could be interesting to inject similar information into other formats. I probably wouldn't bother with single classes, but it could be interesting to inject a META-INF/MANIFEST.MF with similar info into the .jar files we build. This is clearly outside of the scope of *this* proposal, but since people do copy .jar files around, I think it'd make a lot of sense. > What about storing the RPM package identifier by a package manager when > installing a file into an extedned attribute of the file? xattrs are attached to the file itself, so by the time try to collect the coredump, they may be already gone or out of date. The note has the advantage that the loader puts it in memory for us, so we get it when the object is loaded from disk. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
V Wed, Nov 03, 2021 at 01:45:00AM +0100, Miroslav Suchý napsal(a): > Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a): > > === Why not just use the rpm database? === > > > > > > 17:34:33 The main reason for this appears to be that we > > need the RPM db locally to resolve build-ids to package names. But > > since containers wipe /var/lib/rpm, we can't do that. So the solution > > is to put the ''nevra'' in ELF metadata? > > 17:34:39 That feels like the wrong approach. > > > > > > First, there are legitimate reasons to strip packaging metadata from > > images. For example, for an initrd image from rpms, I get 117 MB of > > files (without compression), and out of this `/var/lib/rpm` is 5.9 MB, > > and `/var/lib/dnf` is 4.2 MB. This is an overhead of 9%. This is ''not > > much'', but still too much to keep in the image unless necessary. > > Similar ratios will happen for containers of similar size. Reducing > > image size by one tenth is important. There is no `rpm` or `dnf` in > > the image, to the package database is not even usable without external > > tools. > > Devil advocate here: > > **Some** people wipe `/var/lib/rpm` to save 5.9 MB. And because of this we > will put another 5.9 MB [citation needed] as metadata split across various > ELF objects for **everybody**. > > When someone want really tiny image, I will expect they will start stipping > ELF objects when they discover this feature. > Morover it only pertains ELF. What about other files? E.g. compiled Java classes, or minified JavaScript libriaries? What about storing the RPM package identifier by a package manager when installing a file into an extedned attribute of the file? That would track origin of all files and users not intersted in the tracking could easily remove the data. Effectively it would become a feature of the package manager. Not of a build system. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [HEADS UP] ImageMagick-6.9.12.28
Le 31/10/2021 à 22:44, Luya Tshimbalanga a écrit : Hello team, ImageMagick is updated 6.9.12.28 on Rawhide and got side tag as 35-build-side-47231. For my understanding, the following packages (including those from RPM Fusion) may need a rebuild based on these dependencies: fedora php-pecl-imagick Building php-pecl-imagick-3.5.1-2.fc35 for f35-build-side-47231 Done Remi as proven packager as this package is mostly orphaned (owner is unresponsive) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Zuzana Miklankova
Thank you :). > Please consider joining java-devel mailing list [1] used for > Java-related packaging topics. Thanks for pointing it out, I have just subscribed to this mailing list. Zuzana. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Fedora 35 security update of curl blocked for a month
On Tuesday, November 2, 2021 6:32:34 PM CET Adam Williamson wrote: > 4. The email notifications should be customizable via > https://apps.fedoraproject.org/notifications/ , I believe. I do agree > it would be good if we could tweak some defaults in the notification > code to not notify you when you do things to your own stuff, as you > likely don't need a notification in that case. But I never get around > to doing this for my own account, let alone sending a patch to make it > better for everyone... To be clear, the problem is not that I get notifications for my own actions. I prefer to get such notifications on services like Github or Bugzilla, so that the full story is recorded in my mailbox. The actual problem was that I received the same e-mail 49 times and that its subject nor the body contained any information besides the (currently valid) URL to some JSON data. Kamil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Maíra Canal
On Tue, Nov 02, 2021 at 07:35:24PM -, Maíra Canal via devel wrote: > Hello, > > I'm an undergrad student of Computer Engineering in Brazil. I use Fedora for > about a year as my only OS and I love the philosophy (and the performance) of > Fedora. Currently, I'm looking forward to being a part of the community and > contributing by supporting packages and developing. I have already some > experience contributing to the Linux kernel, but I would like to contribute > to Fedora directly. Hi Maíra, welcome to Fedora. > I'm looking for suggestions of applications to be packaged, so if you have > any, I'm glad to know. If you want to package something new, the NeuroFedora project tracker has a wishlist [1]. But, despite what our docs seem to imply, it is at least as useful, if not more, to provide fixes or upgrades to other packages, e.g. as pull requests on src.fedoraproject.org. [1] https://pagure.io/neuro-sig/NeuroFedora/issues?tags=S%3A+Needs+packaging=Open Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2019407] perl-Sys-Virt-7.9.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2019407 Jitka Plesnikova changed: What|Removed |Added Fixed In Version||perl-Sys-Virt-7.9.0-1.fc36 Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE Last Closed||2021-11-03 07:47:07 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2019407 ___ 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
Re: Fedora 35 security update of curl blocked for a month
On Tuesday, November 2, 2021 8:30:15 PM CET Adam Williamson wrote: > Further to this: I did re-run the tests, they did pass, it did make > Bodhi happy, and I successfully submitted the update to stable. It > should get pushed in the next push, I hope. > > It looks like what happened is that Bodhi didn't update its recorded > gating status for the update when the waivers were submitted. Note > there's two different calculations of the gating status in Bodhi, which > can confuse things. The status you see on the right-hand side of the > web UI - "All required tests passed" or whatever - is actually > generated *by the front end code* whenever your browser loads the page. > The JS front end code runs a (verbose) Greenwave query when you view > the page, and uses the results to generate that status and also the > Automated Tests results list itself. So that status will always be 'up > to date'. > > When you try and push the update, though - whether by clicking on the > button in the web UI, or using the CLI client - Bodhi doesn't use that > status, because the Bodhi back end code doesn't *know* about that > status at all. Instead it checks a property of the update object, which > gets updated...sometimes. The "This update's test gating status has > been changed to XXX" messages that get posted on the update > periodically are actually telling you about *that* status check. > Basically, unless the most recent message was "This update's test > gating status has been changed to passed" or "This update's test gating > status has been changed to ignored", you will not be able to push it. > > I think probably the bit that broke down here is that when you > submitted your waivers, Bodhi didn't get told. The way this is > *currently* supposed to work is that Greenwave listens out for new > waivers, decides whether they change an update push decision, and > publishes a greenwave.decision.update message if so. Bodhi listens for > the greenwave.decision.update messages and either just accepts what > they say or re-calculates the decision (it depends on some other stuff > that doesn't matter rn). Looking through datagrepper logs, I see > waiverdb.waiver.new messages from waiverdb when you created your > waivers, but I *don't* see greenwave.decision.update messages in > response to them. So I think Greenwave messed up and didn't think the > waivers changed the decision. So Bodhi didn't get a message telling it > to re-calculate the gating status, and it stayed at 'failed'. > > There is, I believe, a cron job that runs every few hours or every day > or something that re-calculates the gating status of *every* active > update, so it would probably have got caught up at some point. But it > should really get recalculated as soon as a relevant waiver is > submitted. > > I *hope* this should be fixed in the next Bodhi release, whenever it > gets done and deployed. I actually rewrote how that works completely: > > https://github.com/fedora-infra/bodhi/pull/4230 > > mainly because I considered the existing design to be flat out wrong > (for reasons I won't go into unless you really care :>), but also > because I did, a few months ago, look through the code and find that > greenwave could get this wrong for openQA tests/waivers. I forget the > details, but there's some point at which it makes some assumptions > which are only true for CI tests/waivers. I started out aiming to fix > that, but instead decided the design was wrong and it made more sense > to have Bodhi just listen out for new result / new waiver messages > directly. I believe I wrote that properly so it will work for > waivers/results related to both CI and openQA tests, but we'll find out > for sure when it's deployed, I guess. :D > > Sorry again for the trouble! Thank you for taking care of the update as well as explaining the problem in detail! Kamil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20211103.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20211102.0): ID: 1049866 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1049866 ID: 1049867 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1049867 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
