Re: Possibly off topic: Slack will discontinue packaging for Fedora
On 11/5/21 12:41 AM, Benson Muite wrote: The Mattermost client is open source and will connect to Slack. There are a number of packages in copr: https://copr.fedorainfracloud.org/coprs/fulltext/?fulltext=mattermost Thanks for the suggestion but I prefer the official client for work. Joe -- Joe Doss j...@solidadmin.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possibly off topic: Slack will discontinue packaging for Fedora
The Mattermost client is open source and will connect to Slack. There are a number of packages in copr: https://copr.fedorainfracloud.org/coprs/fulltext/?fulltext=mattermost ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Getting kde/applications/libs on the latest gitlab releases -- tell me what ones I am missing if any
I did all the ones I could see and removed them from here: https://release-monitoring.org/project/8763/ KDE Applications All the rest I did a search for kde and did those as well. Please tell me if/what I am missing (apps/libs,etc) Thanks in advance. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Possibly off topic: Slack will discontinue packaging for Fedora
On 11/4/21 8:55 PM, Joe Doss wrote: It would be cool if we could rally some sort of support on our end to help Slack produce a functioning RPM. I hit up some buds that used to work at Slack to see if they can help connect us with some folks there to work this out. Joe -- Joe Doss j...@solidadmin.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On 11/4/21 7:23 PM, Gordon Messmer wrote: I don't know if that's of interest to Fedora, as an organization, but on the off-chance that it is: Is anyone in a position to ask someone at Slack about that decision? And whether there's anything that Fedora can do to make publishing that package more feasible? I have had an open support ticket for over 6 months with Slack Support about idle detection being totally broken since Fedora 33 on GNOME + Wayland with their RPM. Slack stopped detecting when I was idle on my workstations and it would never send notifications to mobile devices. They responded recently this was working as intended(?) and tried to close the ticket which was a real bummer. Fortunately The flatpak works just fine. It would be cool if we could rally some sort of support on our end to help Slack produce a functioning RPM. Joe -- Joe Doss j...@solidadmin.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possibly off topic: Slack will discontinue packaging for Fedora
as root dnf install dpkg dpkg --force-depends -i slack-desktop-4.21.1-amd64.deb desktop-file-install ./usr/share/applications/slack.desktop works for me , is a "standalone" package we can check with : dpkg-deb --fsys-tarfile slack-desktop-4.21.1-amd64.deb | tar tf - On Thu, 2021-11-04 at 20:35 -0400, JT wrote: > As someone who has to use Slack for work, this is disappointing, but > at least there is still a flatpak for Slack: > https://www.flathub.org/apps/details/com.slack.Slack > > On Thu, Nov 4, 2021 at 8:24 PM Gordon Messmer > wrote: > > https://slack.com/help/articles/115002037526-System-requirements-for-using-Slack > > > > "Note: Starting March 1, 2022, Slack will no longer support Fedora > > Linux > > distributions." > > > > I don't know if that's of interest to Fedora, as an organization, > > but > > on > > the off-chance that it is: Is anyone in a position to ask someone > > at > > Slack about that decision? And whether there's anything that > > Fedora > > can > > do to make publishing that package more feasible? > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/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 -- 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: Possibly off topic: Slack will discontinue packaging for Fedora
As someone who has to use Slack for work, this is disappointing, but at least there is still a flatpak for Slack: https://www.flathub.org/apps/details/com.slack.Slack On Thu, Nov 4, 2021 at 8:24 PM Gordon Messmer wrote: > > https://slack.com/help/articles/115002037526-System-requirements-for-using-Slack > > "Note: Starting March 1, 2022, Slack will no longer support Fedora Linux > distributions." > > I don't know if that's of interest to Fedora, as an organization, but on > the off-chance that it is: Is anyone in a position to ask someone at > Slack about that decision? And whether there's anything that Fedora can > do to make publishing that package more feasible? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Possibly off topic: Slack will discontinue packaging for Fedora
I believe the flatpak on flathub is built on Ubuntu, so there's that, but yes, this is odd and potentially unfortunate. \-- Gwyn Ciesla she/her/hers \ in your fear, seek only peace in your fear, seek only love \-d. bowie Sent from ProtonMail mobile \ Original Message On Nov 4, 2021, 7:23 PM, Gordon Messmer < gordon.mess...@gmail.com> wrote: > > > > https://slack.com/help/articles/115002037526-System-requirements-for-using-Slack > > "Note: Starting March 1, 2022, Slack will no longer support Fedora Linux > distributions." > > I don't know if that's of interest to Fedora, as an organization, but on > the off-chance that it is: Is anyone in a position to ask someone at > Slack about that decision? And whether there's anything that Fedora can > do to make publishing that package more feasible? > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > [https://fedoraproject.org/wiki/Mailing\_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 > [https_fedoraproject.org_wiki_Mailing_list_guidelines]: https://fedoraproject.org/wiki/Mailing_list_guidelines signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Possibly off topic: Slack will discontinue packaging for Fedora
https://slack.com/help/articles/115002037526-System-requirements-for-using-Slack "Note: Starting March 1, 2022, Slack will no longer support Fedora Linux distributions." I don't know if that's of interest to Fedora, as an organization, but on the off-chance that it is: Is anyone in a position to ask someone at Slack about that decision? And whether there's anything that Fedora can do to make publishing that package more feasible? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: llvm 13.0.0-final ABI Change
On 9/30/21 8:03 PM, Tom Stellard wrote: Hi, I'm going to start packaging LLVM 13.0.0-final for rawhide and f35. The 13.0.0-final release has a different ABI than 13.0.0-rc1, so I will be rebuilding the following packages as part of the update: Hi, Now that the f35 freeze is over, I'm going to do the update for f35. The following packages will be rebuilt: american-fuzzy-lop annobin castxml doxygen gnome-builder klee mesa openshadinglanguage qt-creator qt5-qttools qt6-qttools zig - Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [SONAME BUMP] jsoncpp 1.9.5
Am Donnerstag, dem 04.11.2021 um 21:40 +0100 schrieb Björn 'besser82' Esser: > Am Donnerstag, dem 04.11.2021 um 08:54 +0100 schrieb Adrian Reber: > > On Wed, Nov 03, 2021 at 08:10:58PM +0100, Björn 'besser82' Esser > > wrote: > > > 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. > > > > What is your timeline? Usually it is a week between announcing the > > change > > of a SO name and doing the actual builds. You did not mention when > > you > > are planing to do the rebuilds. Just asking as you have packages in > > your > > rebuild list I also have in my protobuf 3.19.0 rebuild list. > > > > Adrian > > > All build have been finished successfully. The side-tag has been > submitted as an update to Bodhi [1] and should be merged with Rawhide > within the next two hours. > > Björn > > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-f230a6fe6a The side-tag is fully merged with Rawhide now. 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: [SONAME BUMP] jsoncpp 1.9.5
Am Donnerstag, dem 04.11.2021 um 08:54 +0100 schrieb Adrian Reber: > On Wed, Nov 03, 2021 at 08:10:58PM +0100, Björn 'besser82' Esser > wrote: > > 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. > > What is your timeline? Usually it is a week between announcing the > change > of a SO name and doing the actual builds. You did not mention when you > are planing to do the rebuilds. Just asking as you have packages in > your > rebuild list I also have in my protobuf 3.19.0 rebuild list. > > Adrian All build have been finished successfully. The side-tag has been submitted as an update to Bodhi [1] and should be merged with Rawhide within the next two hours. Björn [1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-f230a6fe6a 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: F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)
> Rex Dieter writes: > I'm sure there's a way to opt-out of this behavior (right?) There is a standard way to opt out of any of the brp scripts: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Strange mock chainbuild issue: package has incorrect checksum
W dniu 31.10.2021 o 17:07, Sérgio Basto pisze: On Sun, 2021-10-31 at 14:50 +0100, Julian Sikorski wrote: W dniu 20.10.2021 o 20:09, Julian Sikorski pisze: W dniu 29.09.2021 o 10:08, Julian Sikorski pisze: W dniu 28.09.2021 o 09:32, Julian Sikorski pisze: W dniu 22.09.2021 o 21:07, Julian Sikorski pisze: Am 22.09.21 um 19:38 schrieb Fabio Valentini: On Wed, Sep 22, 2021 at 6:35 PM Julian Sikorski wrote: W dniu 21.09.2021 o 23:12, Richard W.M. Jones pisze: On Tue, Sep 21, 2021 at 10:16:17PM +0200, Julian Sikorski wrote: W dniu 21.09.2021 o 11:00, Richard W.M. Jones pisze: On Mon, Sep 20, 2021 at 11:45:39AM -0600, Jerry James wrote: On Mon, Sep 20, 2021 at 10:49 AM Julian Sikorski wrote: my local kernel rebuilds have started failing for no apparent reason - I was using a similar command successfully for several months. /mnt/openmediavault is a samba share. This is what gets output into the log: [snip] /mnt/openmediavault/kernel/results/fedora-34- x86_64/pesign-113-16.fc35/pesign-113- 16.fc34.x86_64.rpm: (39, fsync failed: Permission denied) I suspect that is the real problem, and the incorrect checksum is a result of not being able to read or write the filesystem. Can you verify correct ownership and permissions on every directory in that path? If fsync(2) failed then that would be happening after the file descriptor was open, so it wouldn't be filesystem permissions but probably SELinux. Rich. I am seeing no errors in setroubleshoot and setting selinux to permissive does not help either. Can it be the selinux of the bootstrapped instance, and if so, how can I control it? There is nothing obvious in the logs of the host: AFAIK mock only ever uses one kernel (the host) so disabling SELinux on the host rules out my SELinux theory. Rich. This is all super strange. If I delete the pesign result dir, it is built without issues. Moreover, repodata folder is also created, with the sha256 checksum in the file matching the one of the pesign rpm. What is odd though, is that even after mock fails, gedit is claiming that repomd.xml and the data file extracted from primary.xml.gz keep changing on disk. Can it be some odd system clock issue between my desktop an my NAS? Oh my, that filesystem is mounted over a network? What filesystem is backing that directory? SMB? NFS? I assume that the issue you're seeing is caused by something like "NFS doesn't support the fsync call properly" ... Fabio It is a local network samba share, from a host running armbian and openmediavault. This used to work until last week or so, which is why I am starting to suspect some strange clock problem. I have tried rebooting the NAS but it did not help. Best regards, Julian I have now managed to generate logs on the NAS, see attached. There are two errors which stand out: NT_STATUS_NO_EAS_ON_FILE and NT_STATUS_ACCESS_DENIED later. Does this give any indication as to what might be happening? Best regards, Julian I have been investigating this further. When building from a different client, I am getting most interesting results: $ mock --chain --localrepo=/mnt/openmediavault/kernel -r fedora-34-x86_64 goffice/goffice-0.10.49-1.fc36.src.rpm gnumeric/gnumeric-1.12.49-1.fc36.src.rpm will keep working from the laptop as goffice-0.10.49 was never rebuilt from the desktop, as long as goffice-0.10.50 results folder is not present in /mnt/openmediavault/kernel. $ mock --chain --localrepo=/mnt/openmediavault/kernel -r fedora-34-x86_64 goffice/goffice-0.10.50-2.fc36.src.rpm gnumeric/gnumeric-1.12.50-2.fc36.src.rpm will fail when run from the laptop, even if the goffice-0.10.50- 2.fc36 folder does not exist when the build is started. Moreover, building to a different folder does not work either: $ mock --chain --localrepo=/mnt/openmediavault/kernel1 -r fedora-34-x86_64 goffice/goffice-0.10.50-2.fc36.src.rpm gnumeric/gnumeric-1.12.50-2.fc36.src.rpm This is beyond strange. To me it looks as if either the permissions set from the desktop PC are somehow wrong and additionally persist the folder deletion, or as if createrepo needs different permissions to generate checksum for goffice-0.10.50-2 than for goffice-0.10.49-1. Neither of the above makes too much sense. What does createrepo use to generate the checksum exactly? It would be good to have a simpler reproducer. Best regards, Julian I have looked into this further - running createrepo alone works fine: $ createrepo_c /mnt/openmediavault/kernel/results/fedora-34-x86_64/ Directory walk started Directory walk done - 28 packages Temporary output repo path: /mnt/openmediavault/kernel/results/fedora-34-x86_64/.repodata/ Preparing sqlite DBs Pool started (with 5 workers) Pool finished $ createrepo /mnt/openmediavault/kernel/results/fedora-34-x86_64/ Directory walk started Directory walk done - 28 packages Temporary output repo path: /mnt/openmediavault/kernel/results/fedora-34-x86_64/.repodata/ Preparing sqlite DBs Pool started (with 5 workers) Pool finish
Re: Unexpected /patches VERIFY result from rpminspect
* Aleksei Bavshin: > On 11/4/21 09:17, Florian Weimer wrote: >> Why is this VERIFY? The patch was generated as if by “git show”, and I >> do not see anything wrong with it. > > rpminspect thinks that the patch is suspiciously large and asks you to > confirm that it is intentional. > > There's a test description in the beginning of the log: > > Inspects all patches defined in the spec file and reports changes > between builds. At the INFO level, rpminspect reports diffstat(1) and > patch size changes. If thresholds are reached regarding a change in > the patch size or the number of files the patch touches, rpminspect > reports the change at the VERIFY level unless the comparison is for a > rebase. The configuration file can also list patch names that > rpminspect should ignore during the inspection. Is this a new check? It was flagged as a regression in Jenkins. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F33 EOL closure warnings (or: why did you comment on this bug three times?)
Hi everyone, As you may have noticed, F33 bugs are being updated to remind everyone that F33 will reach EOL on 2021-11-30. In fact, some of you may have noticed three times. As you recall, Red Hat Bugzilla got a 1000-bug limit for queries back in September[1]. So when I was saving the CSV files to feed into the notification script, I naïvely assumed that each CSV file would have the 1000 bugs displayed on that page. Instead, the first page's CSV file had 1000 bugs. The second page's CSV file had 2000 bugs, all the way up to the 6th page which had 5122 bugs. I didn't notice this until mrc0mmand pointed it out to me in IRC, but which time, I had gotten through file 3. So some bugs have 2 or three reminder comments. Sorry for the noise. The last ~1100 are being updated now. I'm verifying the expected behavior with the BZ admins to make sure I properly avoid this the next time around. [1] https://communityblog.fedoraproject.org/changes-to-bugzilla-queries/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unexpected /patches VERIFY result from rpminspect
On 11/4/21 09:17, Florian Weimer wrote: Why is this VERIFY? The patch was generated as if by “git show”, and I do not see anything wrong with it. rpminspect thinks that the patch is suspiciously large and asks you to confirm that it is intentional. There's a test description in the beginning of the log: Inspects all patches defined in the spec file and reports changes between builds. At the INFO level, rpminspect reports diffstat(1) and patch size changes. If thresholds are reached regarding a change in the patch size or the number of files the patch touches, rpminspect reports the change at the VERIFY level unless the comparison is for a rebase. The configuration file can also list patch names that rpminspect should ignore during the inspection. -- Best regards, Aleksei Bavshin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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)
bluca wrote: > This [tags for statically linked parts] would be indeed useful [...] For the original task of assisting with crash analysis, how would it be useful? The idea is that the overall binary's tags would let someone fetch the corresponding distro / debuginfo and go from there. That lookup operation does not need version tags for all the individual bits of source and object code that went into that binary. - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Unexpected /patches VERIFY result from rpminspect
I've got an rpminspect failure I don't understand. Looking at https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/54461/testReport/(root)/tests/_patches/ the relevant result seems to be this: |25) glibc-upstream-2.34-18.patch touches 26 files and as many as 35 lines | |Result: VERIFY |Waiver Authorization: Anyone | |Details: | aarch64/arch-syscall.h |2 ++ | alpha/arch-syscall.h |1 + | arc/arch-syscall.h |1 + | arm/arch-syscall.h |1 + | csky/arch-syscall.h |1 + | hppa/arch-syscall.h |1 + | i386/arch-syscall.h |2 ++ | ia64/arch-syscall.h |1 + | m68k/arch-syscall.h |1 + | microblaze/arch-syscall.h|1 + | mips/mips32/arch-syscall.h |1 + | mips/mips64/n32/arch-syscall.h |1 + | mips/mips64/n64/arch-syscall.h |1 + | nios2/arch-syscall.h |1 + | powerpc/powerpc32/arch-syscall.h |1 + | powerpc/powerpc64/arch-syscall.h |1 + | riscv/rv32/arch-syscall.h|1 + | riscv/rv64/arch-syscall.h|1 + | s390/s390-32/arch-syscall.h |1 + | s390/s390-64/arch-syscall.h |1 + | sh/arch-syscall.h|1 + | sparc/sparc32/arch-syscall.h |1 + | sparc/sparc64/arch-syscall.h |1 + | syscall-names.list |6 -- | x86_64/64/arch-syscall.h |2 ++ | x86_64/x32/arch-syscall.h|2 ++ | 26 files changed, 33 insertions(+), 2 deletions(-) Why is this VERIFY? The patch was generated as if by “git show”, and I do not see anything wrong with it. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)
Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: >> Why would anyone want to do that? (I'm not talking about the case >> mentioned elsewhere in the thread were a non-libtool file is removed >> by a mistake, but the actual case where one would want to keep >> distributing a libtool file.) > > The kdelibs3 plugin loader breaks down horribly if you remove the .la file > under it. (This was fixed in kdelibs 4, but the kdelibs3 compat library > stack still ships those .la files for that reason.) I'm sure there's a way to opt-out of this behavior (right?) -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-20211104.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 24 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 106/206 (x86_64), 62/141 (aarch64) New failures (same test not failed in Fedora-Rawhide-20211103.n.0): ID: 1051765 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1051765 ID: 1051768 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/1051768 ID: 1051808 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/1051808 ID: 1051810 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1051810 ID: 1051811 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1051811 ID: 1051819 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1051819 ID: 1051835 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1051835 ID: 1051837 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1051837 ID: 1051857 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1051857 ID: 1051895 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1051895 ID: 1051915 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1051915 ID: 1051945 Test: aarch64 Server-raw_xz-raw.xz base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/1051945 ID: 1051963 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1051963 ID: 1051976 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1051976 ID: 1051977 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1051977 ID: 1051980 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1051980 ID: 1051994 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/1051994 ID: 1052020 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1052020 ID: 1052021 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1052021 ID: 1052029 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/1052029 ID: 1052032 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1052032 ID: 1052044 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/1052044 ID: 1052047 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/1052047 ID: 1052049 Test: aarch64 universal upgrade_2_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1052049 ID: 1052051 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1052051 ID: 1052071 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1052071 ID: 1052076 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1052076 ID: 1052084 Test: aarch64 universal upgrade_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1052084 ID: 1052086 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1052086 ID: 1052096 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1052096 ID: 1052097 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1052097 ID: 1052098 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/1052098 ID: 1052099 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1052099 ID: 1052120 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/1052120 ID: 1052121 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1052121 ID: 1052122 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1052122 ID: 1052148 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1052148 ID: 1052149 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1052149 ID: 1052
Re: [CoreOS] Fedora CoreOS Community Video Meeting 2021-11-02
On 11/3/21 5:45 PM, Eduard Lucena wrote: > Would you like to have this meeting uploaded to Fedora Project's YouTube > channel? > > Not really sure on that one. Maybe grab me and we'll discuss it. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Nov 4, 2021 at 8:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2021-11-05 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: I just went through and brought our ticket queue on https://github.com/fedora-eln/eln/issues and closed a bunch that are resolved (and noted some that were blocked or stalled). Most of the remaining tickets really relate to improving our documentation, so I'd like to discuss this as our primary topic for tomorrow's meeting. If you have any other items to discuss, please reply to this email and let me know. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora rawhide compose report: 20211104.n.0 changes
On Thu, Nov 4, 2021 at 1:48 PM Fedora Rawhide Report wrote: > > Package: kernel-5.16.0-0.rc0.20211103gitdcd68326d29b.2.fc36 > Old package: kernel-5.15.0-60.fc36 > Summary: The Linux kernel > RPMs: kernel kernel-core kernel-debug kernel-debug-core > kernel-debug-devel kernel-debug-devel-matched kernel-debug-modules > kernel-debug-modules-extra kernel-devel kernel-devel-matched kernel-doc > kernel-lpae kernel-lpae-core kernel-lpae-devel kernel-lpae-devel-matched > kernel-lpae-modules kernel-lpae-modules-extra kernel-lpae-modules-internal > kernel-modules kernel-modules-extra kernel-modules-internal > Dropped RPMs: kernel-debug-modules-internal > Size: 468.71 MiB > Size change: -69.37 MiB > Changelog: > * Tue Nov 02 2021 Fedora Kernel Team > [5.16-0.rc0.20211102gitbfc484fe6abb.1] > - Enable binder for fedora (Justin M. Forbes) > - Reset RHEL_RELEASE for 5.16 (Justin M. Forbes) > - redhat: configs: Update configs for vmware (Kamal Heib) > - Fedora configs for 5.15 (Justin M. Forbes) > - redhat/kernel.spec.template: don't hardcode gcov arches (Jan Stancek) > - redhat/configs: create a separate config for gcov options (Jan Stancek) > - Update documentation with FAQ and update frequency (Don Zickus) > - Document force pull option for mirroring (Don Zickus) > - Ignore the rhel9 kabi files (Don Zickus) > - Remove legacy elrdy cruft (Don Zickus) > - redhat/configs/evaluate_configs: walk cfgvariants line by line (Jan > Stancek) > - redhat/configs/evaluate_configs: insert EMPTY tags at correct place (Jan > Stancek) > - redhat: make dist-srpm-gcov add to BUILDOPTS (Jan Stancek) > - Build CONFIG_SPI_PXA2XX as a module on x86 (Justin M. Forbes) > - redhat/configs: enable CONFIG_BCMGENET as module (Joel Savitz) > - Fedora config updates (Justin M. Forbes) > - Enable CONFIG_FAIL_SUNRPC for debug builds (Justin M. Forbes) > - fedora: Disable fbdev drivers and use simpledrm instead (Javier Martinez > Canillas) > - spec: Don't fail spec build if ksamples fails (Jiri Olsa) > - Enable CONFIG_QCOM_SCM for arm (Justin M. Forbes) > - redhat: Disable clang's integrated assembler on ppc64le and s390x (Tom > Stellard) > - redhat/configs: enable CONFIG_IMA_WRITE_POLICY (Bruno Meneguele) > - Fix dist-srpm-gcov (Don Zickus) > - redhat: configs: add CONFIG_NTB and related items (John W. Linville) > - Add kfence_test to mod-internal.list (Justin M. Forbes) > - Enable KUNIT tests for redhat kernel-modules-internal (Nico Pache) > - redhat: add *-matched meta packages to rpminspect emptyrpm config (Herton > R. Krzesinski) > - Use common config for NODES_SHIFT (Mark Salter) > - redhat: fix typo and make the output more silent for dist-git sync > (Herton R. Krzesinski) > - Fedora NTFS config updates (Justin M. Forbes) > - Fedora 5.15 configs part 1 (Justin M. Forbes) > - Fix ordering in genspec args (Justin M. Forbes) > - redhat/configs: Enable Hyper-V guests on ARM64 (Vitaly Kuznetsov) > [2007430] > - redhat: configs: Enable CONFIG_THINKPAD_LMI (Hans de Goede) > - redhat/docs: update Koji link to avoid redirect (Joel Savitz) > - redhat: add support for different profiles with dist*-brew (Herton R. > Krzesinski) > - redhat: configs: Disable xtables and ipset (Phil Sutter) [1945179] > - redhat: Add mark_driver_deprecated() (Phil Sutter) [1945179] > - Change s390x CONFIG_NODES_SHIFT from 4 to 1 (Justin M. Forbes) > - Build CRYPTO_SHA3_*_S390 inline for s390 zfcpdump (Justin M. Forbes) > - redhat: move the DIST variable setting to Makefile.variables (Herton R. > Krzesinski) > - redhat/kernel.spec.template: Cleanup source numbering (Prarit Bhargava) > - redhat/kernel.spec.template: Reorganize RHEL and Fedora specific files > (Prarit Bhargava) > - redhat/kernel.spec.template: Add include_fedora and include_rhel > variables (Prarit Bhargava) > - redhat/Makefile: Make kernel-local global (Prarit Bhargava) > - redhat/Makefile: Use flavors file (Prarit Bhargava) > - Turn on CONFIG_CPU_FREQ_GOV_SCHEDUTIL for x86 (Justin M. Forbes) > - redhat/configs: Remove CONFIG_INFINIBAND_I40IW (Kamal Heib) > - cleanup CONFIG_X86_PLATFORM_DRIVERS_INTEL (David Arcari) > - redhat: rename usage of .rhel8git.mk to .rhpkg.mk (Herton R. Krzesinski) > - Manually add pending items that need to be set due to mismatch (Justin M. > Forbes) > - Clean up pending common (Justin M. Forbes) > - redhat/configs: Enable CONFIG_BLK_CGROUP_IOLATENCY & > CONFIG_BLK_CGROUP_FC_APPID (Waiman Long) [2006813] > - redhat: remove kernel.changelog-8.99 file (Herton R. Krzesinski) > - redhat/configs: enable CONFIG_SQUASHFS_ZSTD which is already enabled in > Fedora 34 (Tao Liu) [1998953] > - redhat: bump RHEL_MAJOR and add the changelog file for it (Herton R. > Krzesinski) > - redhat: add documentation about the os-build rebase process (Herton R. > Krzesinski) > - redhat/configs: enable SYSTEM_BLACKLIST_KEYRING which is already ena
Fedora rawhide compose report: 20211104.n.0 changes
OLD: Fedora-Rawhide-20211103.n.0 NEW: Fedora-Rawhide-20211104.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 5 Dropped packages:2 Upgraded packages: 114 Downgraded packages: 0 Size of added packages: 33.23 MiB Size of dropped packages:2.30 MiB Size of upgraded packages: 1.63 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -55.85 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: i3 live x86_64 Path: Spins/x86_64/iso/Fedora-i3-Live-x86_64-Rawhide-20211104.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: autorandr-1.11-1.fc36 Summary: Automatically select a display configuration based on connected devices RPMs:autorandr autorandr-bash-completion autorandr-zsh-completion Size:56.21 KiB Package: ghc-OpenGL-3.0.3.0-1.fc36 Summary: A binding for the OpenGL graphics system RPMs:ghc-OpenGL ghc-OpenGL-devel ghc-OpenGL-doc ghc-OpenGL-prof Size:32.12 MiB Package: mingw-qt6-qtlocation-6.2.1-1.fc36 Summary: Qt6 for Windows - QtLocation component RPMs:mingw32-qt6-qtlocation mingw64-qt6-qtlocation Size:691.24 KiB Package: python-tomli-w-0.4.0-1.fc36 Summary: A Python library for writing TOML RPMs:python3-tomli-w Size:17.88 KiB Package: rust-gtk4-0.2.0-1.fc36 Summary: Rust bindings of the GTK 4 library RPMs:rust-gtk4+default-devel rust-gtk4+dox-devel rust-gtk4+v4_2-devel rust-gtk4-devel Size:370.77 KiB = DROPPED PACKAGES = Package: man-pages-es-1.55-36.fc35 Summary: Spanish man pages from the Linux Documentation Project RPMs:man-pages-es man-pages-es-extra Size:2.26 MiB Package: perl-WebService-Dropbox-2.07-14.fc35 Summary: Perl interface to Dropbox API RPMs:perl-WebService-Dropbox Size:42.73 KiB = UPGRADED PACKAGES = Package: R-magick-2.7.3-2.fc36 Old package: R-magick-2.7.3-1.fc36 Summary: Advanced Graphics and Image-Processing in R RPMs: R-magick Size: 23.83 MiB Size change: 7.10 KiB Changelog: * Wed Nov 03 2021 Mamoru TASAKA 2.7.3-2 - rebuld against new ImageMagick (no change to spec) Package: aisleriot-1:3.22.19-1.fc36 Old package: aisleriot-1:3.22.17-1.fc36 Summary: A collection of card games RPMs: aisleriot Size: 31.44 MiB Size change: -818 B Changelog: * Wed Nov 03 2021 David King - 1:3.22.19-1 - Update to 3.22.19 Package: apache-commons-beanutils-1.9.4-8.fc36 Old package: apache-commons-beanutils-1.9.4-7.fc35 Summary: Java utility methods for accessing and modifying the properties of arbitrary JavaBeans RPMs: apache-commons-beanutils apache-commons-beanutils-javadoc Size: 727.99 KiB Size change: -360 B Changelog: * Tue Nov 02 2021 Mikolaj Izdebski - 1.9.4-8 - Bump Java compiler source/target levels to 1.7 Package: apache-commons-collections-3.2.2-25.fc36 Old package: apache-commons-collections-3.2.2-24.fc35 Summary: Provides new interfaces, implementations and utilities for Java Collections RPMs: apache-commons-collections apache-commons-collections-javadoc apache-commons-collections-testframework Size: 1.48 MiB Size change: -55 B Changelog: * Tue Nov 02 2021 Mikolaj Izdebski - 3.2.2-25 - Bump Java compiler source/target levels to 1.7 Package: apache-commons-jxpath-1.3-41.fc36 Old package: apache-commons-jxpath-1.3-40.fc35 Summary: Simple XPath interpreter RPMs: apache-commons-jxpath apache-commons-jxpath-javadoc Size: 824.21 KiB Size change: -43 B Changelog: * Tue Nov 02 2021 Mikolaj Izdebski - 1.3-41 - Bump Java compiler source/target levels to 1.7 Package: apache-commons-logging-1.2-28.fc36 Old package: apache-commons-logging-1.2-27.fc35 Summary: Apache Commons Logging RPMs: apache-commons-logging apache-commons-logging-javadoc Size: 381.42 KiB Size change: 46 B Changelog: * Tue Nov 02 2021 Mikolaj Izdebski - 1.2-28 - Bump Java compiler source/target levels to 1.7 Package: apache-commons-net-3.6-14.fc36 Old package: apache-commons-net-3.6-13.fc35 Summary: Internet protocol suite Java library RPMs: apache-commons-net apache-commons-net-javadoc Size: 991.05 KiB Size change: -122 B Changelog: * Tue Nov 02 2021 Mikolaj Izdebski - 3.6-14 - Set explicit Java compiler source/target levels to 1.7 Package: apiguardian-1.1.2-1.fc36 Old package: apiguardian-1.1.1-3.fc35 Summary: API Guardian Java annotation RPMs: apiguardian apiguardian-javadoc Size: 274.95 KiB Size change: 1 B Changelog: * Tue Nov 02 2021 Mikolaj Izdebski - 1.1.2-1 - Update to upstream version 1.1.2 - Set explicit Java compiler source/target levels to 1.7 Package: atinject-1.0.5-1.fc36 Old package: atinject-1.0.3-3.fc35 Summary: Dependency injection specification for Java (JSR-330) RPMs: atinject atinject-javadoc Size: 285.90 KiB
[Fedocal] Reminder meeting : ELN SIG
Dear all, You are kindly invited to the meeting: ELN SIG on 2021-11-05 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/10108/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Thu, Nov 04, 2021 at 10:26:20AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > We checked compression, and it just isn't worth it. When you compress
> > 100–200 bytes, the output might be a tiny bit smaller, but then the
> > compression alg header is added it becomes a wash. And we lose an important
> > properties of simplicity and ability to read this in a text dump without
> > further processing. It just isn't worth it.
>
> Example:
> $ cat /tmp/payload
> {"type":"rpm","name":"systemd","version":"249.4-1.fc35","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:35"}
> $ for c in zstd gzip xz; do $c -k /tmp/payload; done
> $ ls -l /tmp/f*
> 122 /tmp/f
> 125 /tmp/f.gz
> 172 /tmp/f.xz
> 120 /tmp/f.zst
But a binary representation of that could strip it down into ~50%.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Thu, Nov 04, 2021 at 10:20:35AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Nov 04, 2021 at 11:12:37AM +0100, Jakub Jelinek wrote:
> > On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote:
> > > >> The general case of any statically linked code. It could be libgcc,
> > > >> startup files, the non-shared bits of glibc, static-only libraries, or
> > > >> header-only C++ libraries.
> > >
> > > > This would be indeed useful, but quite harder to do automagically I
> > > > think?
> > >
> > > It requires some level of toolchain support, in compilers and linkers.
> > >
> > > It's unlikely that this would use a JSON-based approach, though. I
> > > think what we want in the linker for this is that it de-duplicates and
> > > merges individual artifact identifiers, so that one ends up with a
> > > single string "glibc-2.34-7.fc35" instead of multiple copies of it. But
> > > I can't see us implementing JSON processing in the linker (all four of
> > > them).
> >
> > I think JSON is a bad idea for the notes in this proposal either, it really
> > wastes memory per process and so should be encoded in some binary form in as
> > few bytes as possible, or perhaps at least compressed JSON.
>
> We checked compression, and it just isn't worth it. When you compress
> 100–200 bytes, the output might be a tiny bit smaller, but then the
> compression alg header is added it becomes a wash. And we lose an important
> properties of simplicity and ability to read this in a text dump without
> further processing. It just isn't worth it.
Example:
$ cat /tmp/payload
{"type":"rpm","name":"systemd","version":"249.4-1.fc35","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:35"}
$ for c in zstd gzip xz; do $c -k /tmp/payload; done
$ ls -l /tmp/f*
122 /tmp/f
125 /tmp/f.gz
172 /tmp/f.xz
120 /tmp/f.zst
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: Fedora 35 Liveimage needs an update
On 04/11/2021 10:28, Marius Schwarz wrote: this has been fixed. So the liveimage needs an update, that people interessed in F35 do no longer get a buggy version when they download it. I'm able to verifiy this, in case the liveimage team wants it tested. You need to wait updated Fedora respins. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Thu, Nov 04, 2021 at 11:12:37AM +0100, Jakub Jelinek wrote: > On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote: > > >> The general case of any statically linked code. It could be libgcc, > > >> startup files, the non-shared bits of glibc, static-only libraries, or > > >> header-only C++ libraries. > > > > > This would be indeed useful, but quite harder to do automagically I > > > think? > > > > It requires some level of toolchain support, in compilers and linkers. > > > > It's unlikely that this would use a JSON-based approach, though. I > > think what we want in the linker for this is that it de-duplicates and > > merges individual artifact identifiers, so that one ends up with a > > single string "glibc-2.34-7.fc35" instead of multiple copies of it. But > > I can't see us implementing JSON processing in the linker (all four of > > them). > > I think JSON is a bad idea for the notes in this proposal either, it really > wastes memory per process and so should be encoded in some binary form in as > few bytes as possible, or perhaps at least compressed JSON. We checked compression, and it just isn't worth it. When you compress 100–200 bytes, the output might be a tiny bit smaller, but then the compression alg header is added it becomes a wash. And we lose an important properties of simplicity and ability to read this in a text dump without further processing. It just isn't worth it. It does "waste" memory, but let's take this in context. The amount of memory is so tiny that it'd be like saying that we should use abbreviations in status messages to save dozens of bytes… One icon in one app is more than this overhead for all other processes running on the system. 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: Fedora 32 System-Wide Change proposal: iptables-nft-default
Hi Bex, On Thu, Oct 21, 2021 at 12:58:11PM +0200, Brian (bex) Exelbierd wrote: > On Thu, Oct 21, 2021 at 3:23 AM Phil Sutter wrote: > > On Wed, Oct 20, 2021 at 01:40:35PM -0700, Adam Williamson wrote: > > > On Wed, 2021-10-20 at 18:39 +0200, Brian (bex) Exelbierd wrote: > > [...] > > > > AIUI, we made the change to use iptables-nft as the default with F32. > > We > > > > also decided that existing iptables-legacy users shouldn't be moved to > > > > iptables-nft during an upgrade. > > > > > > > > However, I think that new installations are still defaulting to > > > > iptables-legacy. The group "Common NetworkManager Submodules" pulls in > > > > `iptables` which seems to pull in iptables-legacy by default. > > > > > > > > This feels like an oversight and should be fixed. Is this correct? > > > > I just had a bright moment! It told me to check fedora-comps: Indeed the > > above issue was reported[1] and fixed[2] for F35. > > > > Thank you for catching the update is already in the works. > > Does this also remove iptables-compat? I gather from its description it > should have been removed by now. The -compat package is merely there as transitioning aid during updates. It provides no functionality at all. The relevant pieces are: * nftables - the successor to (old) iptables, all new, no bounds * iptables-legacy - the old iptables, not related to nftables at all * iptables-nft - a drop-in replacement to -legacy, using nftables with (some) legacy matches/targets The decision between legacy and nft variants of iptables happens via alternatives. Switching should not be noticeable to users apart from corner-cases. > I also can't help but wonder what the impact of this change will be on > OSTree users. Will they be force upgraded from iptables to nftables > through the removal? A key point in the above is that 'dnf update' won't change the currently used variant on a system. New installs should default to iptables-nft, though. I'm not familiar with ostree, so I can't tell if this promise holds there. If it doesn't and we can fix it in RPM, please let me know (or just file a ticket so we can track it). Cheers, Phil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote: > * Luca Boccassi: > > >> * Zbigniew Jędrzejewski-Szmek: > >> > >> > >> The general case of any statically linked code. It could be libgcc, > >> startup files, the non-shared bits of glibc, static-only libraries, or > >> header-only C++ libraries. > > > This would be indeed useful, but quite harder to do automagically I > > think? > > It requires some level of toolchain support, in compilers and linkers. > > It's unlikely that this would use a JSON-based approach, though. I > think what we want in the linker for this is that it de-duplicates and > merges individual artifact identifiers, so that one ends up with a > single string "glibc-2.34-7.fc35" instead of multiple copies of it. But > I can't see us implementing JSON processing in the linker (all four of > them). Maybe this should be done at different level altogether: rpms have dynamically generated requires/provides. Maybe we should have something as part of the build process that generates 'Provides: bundled(foo) = …' for every package that provides "static elements" that is present on the build system / or listed in build requires if that'd be possible. (Packages that provide "static elements" would be those that have -static in the name or are header only -devel packages. We could use some heuristics and/or mark them appropriate using virtual Provides.) This would probably be a lot easier to implement than a language that is embedded in ELF files… It could also be made to work for some strange cases like a .jar file embedding an .so. 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)
On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote: > >> The general case of any statically linked code. It could be libgcc, > >> startup files, the non-shared bits of glibc, static-only libraries, or > >> header-only C++ libraries. > > > This would be indeed useful, but quite harder to do automagically I > > think? > > It requires some level of toolchain support, in compilers and linkers. > > It's unlikely that this would use a JSON-based approach, though. I > think what we want in the linker for this is that it de-duplicates and > merges individual artifact identifiers, so that one ends up with a > single string "glibc-2.34-7.fc35" instead of multiple copies of it. But > I can't see us implementing JSON processing in the linker (all four of > them). I think JSON is a bad idea for the notes in this proposal either, it really wastes memory per process and so should be encoded in some binary form in as few bytes as possible, or perhaps at least compressed JSON. For the package NVR gathering from all the *.o/*.a files, I'm not sure you need much toolchain support, just let some brp-* policy file inject a SHF_MERGE|SHF_STRINGS (and please, non-SHF_ALLOC!) note section with sh_addralign 1 and the linkers should DTRT already. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
* Luca Boccassi: >> * Zbigniew Jędrzejewski-Szmek: >> >> >> The general case of any statically linked code. It could be libgcc, >> startup files, the non-shared bits of glibc, static-only libraries, or >> header-only C++ libraries. > This would be indeed useful, but quite harder to do automagically I > think? It requires some level of toolchain support, in compilers and linkers. It's unlikely that this would use a JSON-based approach, though. I think what we want in the linker for this is that it de-duplicates and merges individual artifact identifiers, so that one ends up with a single string "glibc-2.34-7.fc35" instead of multiple copies of it. But I can't see us implementing JSON processing in the linker (all four of them). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
* Steve Grubb:
> 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?
There are variants which are not visible in the ELF header (e.g.,
different ISA levels or calling conventions for floating point), or not
visible at the ELF level (e.g., alternative builds with CPU-specific
optimizations that are automatically loaded by glibc). Using “arm32”
suggests that one isn't really interested in this level of detail,
though.
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211104.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-20211103.0): ID: 1051516 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1051516 ID: 1051517 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1051517 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
Fedora 35 Liveimage needs an update
Hi, On the first test of F35 Livedisk we found a Bug in "gnome-connections". According to: https://bugzilla.redhat.com/show_bug.cgi?id=2019610 this has been fixed. So the liveimage needs an update, that people interessed in F35 do no longer get a buggy version when they download it. I'm able to verifiy this, in case the liveimage team wants it tested. best regards, Marius Schwarz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Thanks for your info! OK. Yes, I installed Fedora 35 beta to the 2TB SSD before installing Fedora 35 RC 1.2 in this case. So, there is existing data already on the 2TB SSD. Where is the “make additional space available” link? And the wild thing is when I selected (checked) only one disk "2 TB SSD" on the first screen shot, the “Click here to create them automatically” link worked, removing existing data. Jun On Thu, Nov 4, 2021 at 2:59 AM Moses Denny via devel wrote: > > 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 < jar...@redhat.com> 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 -- 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
Fedora-Cloud-35-20211104.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-20211103.0): ID: 1051384 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1051384 ID: 1051385 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1051385 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: [SONAME BUMP] jsoncpp 1.9.5
On Wed, Nov 03, 2021 at 08:10:58PM +0100, Björn 'besser82' Esser wrote: > 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. What is your timeline? Usually it is a week between announcing the change of a SO name and doing the actual builds. You did not mention when you are planing to do the rebuilds. Just asking as you have packages in your rebuild list I also have in my protobuf 3.19.0 rebuild list. Adrian 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
Fedora-Cloud-33-20211104.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-20211103.0): ID: 1051368 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1051368 ID: 1051369 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1051369 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
