Fedora-Cloud-33-20201219.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20201218.0): ID: 744289 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/744289 ID: 744296 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/744296 Passed openQA tests: 6/7 (x86_64), 6/7 (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
[Bug 1909332] New: perl-DateTime-Format-W3CDTF-0.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909332 Bug ID: 1909332 Summary: perl-DateTime-Format-W3CDTF-0.08 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-Format-W3CDTF Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.08 Current version/release in rawhide: 0.07-12.fc33 URL: http://search.cpan.org/dist/DateTime-Format-W3CDTF/ 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/7089/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[389-devel] 389 DS nightly 2020-12-19 - 91% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/12/19/report-389-ds-base-1.4.4.9-1.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On 2020-12-18 11:13 a.m., Robbie Harwood wrote: clime writes: On Fri, 18 Dec 2020 at 18:20, Robbie Harwood wrote: Robert-André Mauchin writes: On 12/18/20 3:52 PM, James Szinger wrote: No. One can also download the sources from upstream using spectool or similar, even wget or curl. My local work flow is typically get or create spec file and patches, spectool -g, rpmbuild -bs, mock. Unrelated to the topic at hand, but why do people still use rpmbuild -bs instead of using a fedpkg mockbuild? You get a clean environment to build and you don't have to install tons of devel packages on your system. For me it's speed. Yes, mock gives a clean environment, but I'd rather not use it if I don't have to: the tradeoff is I don't have to *wait* for the mock to go get the tons of devel packages (and generally for repo/dnf slowness) - they're already installed on my system. But you have fedpkg installed, right? I think fedpkg srpm should do a good job as well. Probably, but that wasn't the question - the question was about mockbuild. Thanks, --Robbie Mockbuild stores packages in /var/lib/mock and will skip those already downloaded. You can configure dnf (slowness is a illusion because the package manager does many task as verify the security and possible update packages) to only use cache when needed at the cost of getting outdated packages. Make sure to select the fastest mirror for effectiveness -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1909317] New: perl-Moose-2.2014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909317 Bug ID: 1909317 Summary: perl-Moose-2.2014 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Moose Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, lkund...@v3.sk, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 2.2014 Current version/release in rawhide: 2.2013-2.fc33 URL: http://search.cpan.org/dist/Moose/ 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/6197/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1908799] perl-LWP-Protocol-https-6.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1908799 --- Comment #5 from Fedora Update System --- FEDORA-2020-6296f09d90 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6296f09d90` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6296f09d90 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1908474] perl-libwww-perl-6.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1908474 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-libwww-perl-6.50-1.fc3 |perl-libwww-perl-6.50-1.fc3 |4 |4 ||perl-libwww-perl-6.50-1.fc3 ||3 Resolution|--- |ERRATA Last Closed||2020-12-19 01:16:31 --- Comment #6 from Fedora Update System --- FEDORA-2020-b66683a2df 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. ___ 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
[Bug 1908799] perl-LWP-Protocol-https-6.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1908799 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2020-d7f21b3224 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d7f21b3224` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d7f21b3224 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Thu, Dec 17, 2020 at 2:19 PM Troy Dawson wrote: > > On Wed, Dec 9, 2020 at 3:52 PM Miro Hrončok wrote: > > > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > > > ... > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > Should there be an update of: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/ > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ > > > > ? > > > Working on the Node.js documentation right now. > I currently haven't tested any of the bundling with javascript > (js-...) packages. So I am not confident in writing documentation for > them. > It looks like there is only 20 left in Fedora. I am thinking of > putting them in on our exceptions list, along with binary nodejs > libraries. So we would get to them at a future time. > > Troy The Node.js packaging Guidelines have a pull request for their update. https://pagure.io/packaging-committee/pull-request/1034 I did not touch the Javascript documentation. I took another look at the 20 javascript packages. Only two of them come from nodejs- libraries. Both of those two look like we can remove the nodejs- runtime package (server side javascript) and leave the js- runtime package (browser side javascript). Troy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Fri, Dec 11, 2020 at 9:32 AM Troy Dawson wrote: > > On Fri, Dec 11, 2020 at 3:18 AM Till Maas wrote: > > > > Hi, > > > > this does not seem to be self-contained, since it seems to affect people > > outside the SIG (it states that this is also affecting packages that are > > not owned by the SIG). > > > > On Wed, Dec 09, 2020 at 01:44:30PM -0500, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > > > == Summary == > > > > > > For Nodejs, Fedora should only package: > > > * The interpreter, development headers/libraries, and the assorted > > > tools to manage project-level installations (NPM, yarn, etc.). > > > * Packages that provide binaries that users would want to use in their > > > shell. > > > * compiled/binary nodejs modules (for now) > > > > > > == Owner == > > > > > > * Name: [[User:tdawson| Troy Dawson]] > > > * Email: tdaw...@redhat.com > > > * Name: [[User:sgallagh| Stephen Gallagher]] > > > * Email: sgall...@redhat.com > > > * Name: > > > [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > > > Nodejs SIG]] > > > * Email: nod...@lists.fedoraproject.org > > > > > > > > > == Detailed Description == > > > > > > The nodejs libraries have been approved to be bundled, and there is > > > infrastructure in place for the bundling to work properly. Currently, > > > > What does this infrastructure look like? How does it help with > > addressing security issues in the bundles components effectivly? > > > > > it is recommended that packagers should create individual nodejs > > > library packages instead of bundling all of the libraries into the > > > package requiring them. > > > > The subject says "Stop Shipping Individual Nodejs Library Packages", > > therefore it would be more clear to block all Nodejs libraries in Fedora > > instead of only recommending this. Otherwise it will be some half-baked > > solution that is probably confusing (Why are some libraries packaged and > > others bundled?). > > > > > This change is to make it default to bundle the nodejs libraries with > > > the package that needs them, and retire the vast majority of nodejs > > > library packages. > > > In summary, for Nodejs Fedora should only package: > > > * The interpreter, development headers/libraries, and the assorted > > > tools to manage project-level installations (NPM, yarn, etc.). > > > * Packages that provide binaries that users would want to use in their > > > shell. > > > * compiled/binary nodejs modules (for now) > > > > This should also include the tooling that is needed to manage the > > bundling. > > > > > > > == Feedback == > > > > > > There has been a discussion on the fedora nodejs mailing list about > > > what to do with the extreme dependency problem of the nodejs library > > > packages. Because of the extreme inter-dependency, upgrading almost > > > any package causes others to break. It has caused most packages to > > > rot, remaining on unsupported versions for years. Many of the nodejs > > > packagers are giving up and orphaning their packages, which has caused > > > even more problems. > > > > > > An initial proposal was to find all of the important nodejs library > > > packages and bundle those, making them easier to upgrade and maintain. > > > But there was problems with figuring out what was important, and what > > > versions should those have. During that discussion, this rather > > > extreme solution of getting rid of all nodejs libraries was proposed. > > > To our surprise, it has been the best received suggestion and fixes > > > the most problems. > > > > What problems remain? > > > > > > > > == Benefit to Fedora == > > > > > > * In Fedora 33, there are many nodejs libraries that are > > > uninstallable, thus causing other programs based off them to also be > > > uninstallable. This gets rid of that problem. > > > * Packages in Fedora that use nodejs libraries will be able to use the > > > library versions that upstream has tested and approved. > > > * If a package in Fedora uses a nodejs library, the packager will not > > > have to also package extra individual nodejs library packages. There > > > have been times this has led to over 100 extra packages, each with > > > their own package reviews and maintenance problems. This change will > > > lower the workload on that packager, and possibly get more packages > > > into Fedora. > > > * The nodejs maintainers can concentrate on nodejs itself, instead of > > > the whole nodejs library infrastructure. > > > * Nodejs developers using Fedora will no longer have to worry about > > > Fedora's global nodejs libraries causing conflicts or inconsistencies. > > > > > > == Scope == > > > * Proposal owners: > > > We will go through the Fedora release and determine what nodejs > > > packages Fedora should package. We will implement nodejs library > > > bundling on those we already own. For those that we do not own, we > > > will work with their owners to implement nodejs
Re: Problems upgrading to f33 cloud edition
Il giorno ven, 18/12/2020 alle 22.42 +0100, Marius Schwarz ha scritto: > Am 18.12.20 um 20:37 schrieb Guido Aulisi: > > > > Yes, but I found an issue regarding this list: > > Package hwdata in F32 is newer than the one in F33. > > > > hwdata-0.342-1.fc32 | hwdata-0.341-1.fc33 > > This happens with different packages from time to time and is nothing > special. > > Try this for your upgrade and see what happens ( add the -x exclude > if > still needed ) > > rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-$(uname -i) > dnf --allowerasing --releasever=33 --setopt=deltarpm=false distro- > sync > > If a dependency blocks you, you can simply erase the package manually I succeeded in upgrading the system, but I had to remove NetworkManager and reinstall it later. The strange thing is that I didn't have console-login-helper-messages installed in f32, maybe it's pulled in by some group in f33. Thaks for help. Guido > before you upgrade, an reinstall it later. > > > best regards, > Marius > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Problems upgrading to f33 cloud edition
Am 18.12.20 um 20:37 schrieb Guido Aulisi: Yes, but I found an issue regarding this list: Package hwdata in F32 is newer than the one in F33. hwdata-0.342-1.fc32 | hwdata-0.341-1.fc33 This happens with different packages from time to time and is nothing special. Try this for your upgrade and see what happens ( add the -x exclude if still needed ) rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-$(uname -i) dnf --allowerasing --releasever=33 --setopt=deltarpm=false distro-sync If a dependency blocks you, you can simply erase the package manually before you upgrade, an reinstall it later. best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1908816] perl-DBD-CSV-0.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1908816 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-DBD-CSV-0.57-1.fc34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-12-18 20:42:20 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=57743281 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Problems upgrading to f33 cloud edition
Il giorno ven, 18/12/2020 alle 10.33 -0700, stan via devel ha scritto: > On Fri, 18 Dec 2020 10:25:30 +0100 > Guido Aulisi wrote: > > > Hi, sorry for posting here if this is not correct. > > Probably more appropriate for the user list. Yes, but I found an issue regarding this list: Package hwdata in F32 is newer than the one in F33. hwdata-0.342-1.fc32 | hwdata-0.341-1.fc33 > > I'm upgraing a f32 cloud edition to f33 and I found this problem > > which > > I can't solve: > > > > $ sudo dnf system-upgrade --releasever 33 --skip-broken > > --allowerasing -vvv download > > > > I get this response: > > > > Error: > > Problem: conflicting requests > > - package > > console-login-helper-messages-issuegen-0.20.3-1.fc33.noarch > > requires > > NetworkManager, but none of the providers can be installed > > - package > > console-login-helper-messages-issuegen-0.20.1-1.fc33.noarch > > requires > > NetworkManager, but none of the providers can be installed > > It seems that something wants to install > console-login-helper-messages-issuegen > but the NetworkManager packages the only available versions can use > cannot be installed, probably because there is a later version being > installed. > > > I don't have console-login-helper-messages installed in f32. > > You could try > > $ sudo dnf -x console-login-helper-messages-issuegen system-upgrade > --releasever 33 --skip-broken --allowerasing -vvv download > > so that it skips the install of whatever is requiring > console-login-helper-messages-issuegen. At the least that should show > you what the chain of dependencies is that is dragging in > console-login-helper-messages. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
clime writes: > On Fri, 18 Dec 2020 at 18:20, Robbie Harwood wrote: >> >> Robert-André Mauchin writes: >> >> > On 12/18/20 3:52 PM, James Szinger wrote: >> >> >> >> No. One can also download the sources from upstream using spectool or >> >> similar, even wget or curl. My local work flow is typically get or >> >> create spec file and patches, spectool -g, rpmbuild -bs, mock. >> >> >> > >> > Unrelated to the topic at hand, but why do people still use rpmbuild -bs >> > instead of using a fedpkg mockbuild? You get a clean environment to >> > build and you don't have to install tons of devel packages on your system. >> >> For me it's speed. Yes, mock gives a clean environment, but I'd rather >> not use it if I don't have to: the tradeoff is I don't have to *wait* >> for the mock to go get the tons of devel packages (and generally for >> repo/dnf slowness) - they're already installed on my system. > > But you have fedpkg installed, right? I think fedpkg srpm should do a > good job as well. Probably, but that wasn't the question - the question was about mockbuild. Thanks, --Robbie 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
Re: Problems upgrading to f33 cloud edition
On Fri, 18 Dec 2020 10:25:30 +0100 Guido Aulisi wrote: > Hi, sorry for posting here if this is not correct. Probably more appropriate for the user list. > I'm upgraing a f32 cloud edition to f33 and I found this problem which > I can't solve: > > $ sudo dnf system-upgrade --releasever 33 --skip-broken > --allowerasing -vvv download > > I get this response: > > Error: > Problem: conflicting requests > - package > console-login-helper-messages-issuegen-0.20.3-1.fc33.noarch requires > NetworkManager, but none of the providers can be installed > - package > console-login-helper-messages-issuegen-0.20.1-1.fc33.noarch requires > NetworkManager, but none of the providers can be installed It seems that something wants to install console-login-helper-messages-issuegen but the NetworkManager packages the only available versions can use cannot be installed, probably because there is a later version being installed. > I don't have console-login-helper-messages installed in f32. You could try $ sudo dnf -x console-login-helper-messages-issuegen system-upgrade --releasever 33 --skip-broken --allowerasing -vvv download so that it skips the install of whatever is requiring console-login-helper-messages-issuegen. At the least that should show you what the chain of dependencies is that is dragging in console-login-helper-messages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On Fri, 18 Dec 2020 at 18:20, Robbie Harwood wrote: > > Robert-André Mauchin writes: > > > On 12/18/20 3:52 PM, James Szinger wrote: > >> > >> No. One can also download the sources from upstream using spectool or > >> similar, even wget or curl. My local work flow is typically get or > >> create spec file and patches, spectool -g, rpmbuild -bs, mock. > >> > > > > Unrelated to the topic at hand, but why do people still use rpmbuild -bs > > instead of using a fedpkg mockbuild? You get a clean environment to > > build and you don't have to install tons of devel packages on your system. > > For me it's speed. Yes, mock gives a clean environment, but I'd rather > not use it if I don't have to: the tradeoff is I don't have to *wait* > for the mock to go get the tons of devel packages (and generally for > repo/dnf slowness) - they're already installed on my system. But you have fedpkg installed, right? I think fedpkg srpm should do a good job as well. > > Thanks, > --Robbie > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
Robert-André Mauchin writes: > On 12/18/20 3:52 PM, James Szinger wrote: >> >> No. One can also download the sources from upstream using spectool or >> similar, even wget or curl. My local work flow is typically get or >> create spec file and patches, spectool -g, rpmbuild -bs, mock. >> > > Unrelated to the topic at hand, but why do people still use rpmbuild -bs > instead of using a fedpkg mockbuild? You get a clean environment to > build and you don't have to install tons of devel packages on your system. For me it's speed. Yes, mock gives a clean environment, but I'd rather not use it if I don't have to: the tradeoff is I don't have to *wait* for the mock to go get the tons of devel packages (and generally for repo/dnf slowness) - they're already installed on my system. Thanks, --Robbie 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
[rpms/perl-Sys-Virt-TCK] PR #1: SELinux policy for Libvirt-TCK
nknazeko opened a new pull-request against the project: `perl-Sys-Virt-TCK` that you are following: `` SELinux policy for Libvirt-TCK `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Sys-Virt-TCK/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[rpms/perl-Sys-Virt-TCK] PR #1: SELinux policy for Libvirt-TCK
nknazeko commented on the pull-request: `SELinux policy for Libvirt-TCK ` that you are following: `` Introduce SELinux policy for Libvirt-TCK Introduce SELinux policy subpackage for Libvirt-TCK, created for testing SELinux policy for virt drivers. Libvirt-TCK module runs in permissive. Copr build of Libvirt-TCK with SELinux subpackage: https://copr.fedorainfracloud.org/coprs/nknazeko/libvirt-tck-selinux/ Libvirt test suite gives AVC messages related to this bug: [BZ1858260 - SELinux prevents svirt_t read|write on lvm_control_t during VM creation](https://bugzilla.redhat.com/show_bug.cgi?id=1858260) `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Sys-Virt-TCK/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
Hello, On Fri, Dec 18, 2020 at 5:53 PM Robert-André Mauchin wrote: > > On 12/18/20 3:52 PM, James Szinger wrote: > > > > No. One can also download the sources from upstream using spectool or > > similar, even wget or curl. My local work flow is typically get or > > create spec file and patches, spectool -g, rpmbuild -bs, mock. > > > > Unrelated to the topic at hand, but why do people still use rpmbuild -bs > instead of using a fedpkg mockbuild? You get a clean environment to > build and you don't have to install tons of devel packages on your system. I think 'rpmbuild -bs' is the quickest way to a source rpm package and it doesn't require any dependencies to be installed on your system. My workflow is almost identical to that of James and that first srpm might get reused multiple times before I get the one from mock. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On 12/18/20 3:52 PM, James Szinger wrote: No. One can also download the sources from upstream using spectool or similar, even wget or curl. My local work flow is typically get or create spec file and patches, spectool -g, rpmbuild -bs, mock. Unrelated to the topic at hand, but why do people still use rpmbuild -bs instead of using a fedpkg mockbuild? You get a clean environment to build and you don't have to install tons of devel packages on your system. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
On Fri, 2020-12-18 at 07:33 -0700, James Szinger wrote: > On Tue, 15 Dec 2020 11:17:21 -0800 > Kevin Fenzi wrote: > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > > will stop working. Worse they will appear corrupted, so you will have > > to remove them and re-install them (after downgrading nss). > > > > For now, downgrade nss or avoid updating to it until things can get > > sorted out. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1908018 > > > > kevin > > I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or > are there going to be a lot of unhappy Firefox users? It's fixed. > The bug is still open. Because we still need to do something (or, rather, get Mozilla to do something) about the underlying situation. -- 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
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On Fri, 18 Dec 2020 at 15:53, James Szinger wrote: > > On Fri, 18 Dec 2020 03:04:01 +0100 > clime wrote: > > > I wouldn't call it "deprecating rpmbuild". That's certainly not at all > > my intention. > > > > As a side-point, I think the cases where bare rpmbuild is used to > > build an rpm/srpm from a dist-git repo are rather limited because you > > probably need to first download sources from lookaside cache so you > > probably need fedpkg/rpkg/centpkg/rfpkg or a similar dedicated tool. > > These tools then offer the `srpm` and `local` commands so It would > > make sense to rather use these commands or mock for subsequent > > srpm/rpm building. > > No. One can also download the sources from upstream using spectool or > similar, even wget or curl. My local work flow is typically get or > create spec file and patches, spectool -g, rpmbuild -bs, mock. > > I could not find simple instructions for the *pkg tools the last time > I looked. It should be just `fedpkg srpm` for a Fedora package. Or `rpkg srpm` with rpkg-util tool. spectool could contain native support for preprocessing as well, I will look at opening a PR for it. I think with rpmbuild something like: `rpmbuild --define "%_sourcedir $PWD" -bs file.spec` is needed, right? There is also yum/dnf builddep command that I wanted to look at. > > Jim > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On Fri, 18 Dec 2020 at 16:23, James Szinger wrote: > > On Fri, 18 Dec 2020 00:51:49 +0100 > clime wrote: > > > Well, the users here are still packagers here no? I thought the "User" > > in the title means "end user" who shouldn't be affected by it. Maybe > > Ben can clarify this. > > I am making a distinction between Fedora packagers who use the Fedora > infrastructure to build RPMs for the Fedora repositories, and second > and third party packagers who use their own infrastructure. External > packagers count as ‘users’ for the purposes of change proposals, > especially infrastructure changes such as this. Many change proposals > have no effect for external packagers, or have the same effect as for > the general user base. This proposal, however, seems potentially > disruptive for external packagers, and I want to see those issues > specifically addressed in the change proposal. > > I will advocate that external packagers are of strategic importance to > the Fedora Project. The software they provide encourages the adoption > of Fedora. They form a pool a potential Fedora packagers. They are > the technical experts that support the local users. They are > fundamental to the Fedora Mission: > > Fedora creates an innovative platform for hardware, clouds, and > containers that enables software developers and community members > to build tailored solutions for their users. > > Supporting external packagers drives the Four Foundations: Freedom, > Friends, Features, and First. I agree the change proposal should address those issues. > > Jim > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mass spec file change: Adding BuildRequires: make
On 11/30/20 2:06 PM, Tom Stellard wrote: Hi, As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed. If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update. I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes: Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Were are the packages I'll be updating today: https://fedorapeople.org/~tstellar/br_make_day3.txt -Tom Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages. The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20). Thanks, Tom [1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20201218.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 11/180 (x86_64), 15/122 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201217.n.0): ID: 743537 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/743537 ID: 743541 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/743541 ID: 743544 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/743544 ID: 743546 Test: x86_64 Workstation-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/743546 ID: 743551 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/743551 ID: 743595 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/743595 ID: 743600 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/743600 ID: 743605 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/743605 ID: 743778 Test: aarch64 universal install_mirrorlist_graphical@uefi URL: https://openqa.fedoraproject.org/tests/743778 ID: 743794 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/743794 ID: 743797 Test: aarch64 Workstation-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/743797 ID: 743801 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/743801 ID: 743803 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/743803 Old failures (same test failed in Fedora-Rawhide-20201217.n.0): ID: 743519 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/743519 ID: 743549 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/743549 ID: 743559 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/743559 ID: 743568 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/743568 ID: 743620 Test: aarch64 Server-dvd-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/743620 ID: 743667 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/743667 ID: 743722 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/743722 ID: 743749 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/743749 ID: 743760 Test: aarch64 universal install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/743760 ID: 743776 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/743776 ID: 743781 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/743781 ID: 743782 Test: aarch64 universal install_serial_console@uefi URL: https://openqa.fedoraproject.org/tests/743782 ID: 743785 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/743785 Soft failed openQA tests: 19/180 (x86_64), 14/122 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20201217.n.0): ID: 743518 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/743518 ID: 743619 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/743619 ID: 743753 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/743753 ID: 743788 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/743788 ID: 743791 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/743791 Old soft failures (same test soft failed in Fedora-Rawhide-20201217.n.0): ID: 743488 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/743488 ID: 743489 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/743489 ID: 743496 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/743496 ID: 743500 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/743500 ID: 743504
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On Fri, 18 Dec 2020 00:51:49 +0100 clime wrote: > Well, the users here are still packagers here no? I thought the "User" > in the title means "end user" who shouldn't be affected by it. Maybe > Ben can clarify this. I am making a distinction between Fedora packagers who use the Fedora infrastructure to build RPMs for the Fedora repositories, and second and third party packagers who use their own infrastructure. External packagers count as ‘users’ for the purposes of change proposals, especially infrastructure changes such as this. Many change proposals have no effect for external packagers, or have the same effect as for the general user base. This proposal, however, seems potentially disruptive for external packagers, and I want to see those issues specifically addressed in the change proposal. I will advocate that external packagers are of strategic importance to the Fedora Project. The software they provide encourages the adoption of Fedora. They form a pool a potential Fedora packagers. They are the technical experts that support the local users. They are fundamental to the Fedora Mission: Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users. Supporting external packagers drives the Four Foundations: Freedom, Friends, Features, and First. Jim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1909154] perl-ExtUtils-Install-2.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909154 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-ExtUtils-Install-2.20- ||1.fc34 Resolution|--- |RAWHIDE Last Closed||2020-12-18 15:16:02 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Fedora-IoT-34-20201218.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 7/15 (aarch64), 1/16 (x86_64) New failures (same test not failed in Fedora-IoT-34-20201217.0): ID: 743831 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/743831 ID: 743834 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/743834 Old failures (same test failed in Fedora-IoT-34-20201217.0): ID: 743811 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/743811 ID: 743820 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/743820 ID: 743822 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/743822 ID: 743823 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/743823 ID: 743825 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/743825 ID: 743829 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/743829 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20201217.0): ID: 743804 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/743804 Passed openQA tests: 14/16 (x86_64), 8/15 (aarch64) New passes (same test not passed in Fedora-IoT-34-20201217.0): ID: 743814 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_rebase URL: https://openqa.fedoraproject.org/tests/743814 Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.37 to 0.50 Previous test data: https://openqa.fedoraproject.org/tests/742812#downloads Current test data: https://openqa.fedoraproject.org/tests/743821#downloads -- 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
Re: libQt5WebEngineCore.so: undefined reference to `PK11_SignatureLen@NSS_3.2'
many thanks for your workaround. Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On Fri, 18 Dec 2020 03:04:01 +0100 clime wrote: > I wouldn't call it "deprecating rpmbuild". That's certainly not at all > my intention. > > As a side-point, I think the cases where bare rpmbuild is used to > build an rpm/srpm from a dist-git repo are rather limited because you > probably need to first download sources from lookaside cache so you > probably need fedpkg/rpkg/centpkg/rfpkg or a similar dedicated tool. > These tools then offer the `srpm` and `local` commands so It would > make sense to rather use these commands or mock for subsequent > srpm/rpm building. No. One can also download the sources from upstream using spectool or similar, even wget or curl. My local work flow is typically get or create spec file and patches, spectool -g, rpmbuild -bs, mock. I could not find simple instructions for the *pkg tools the last time I looked. Jim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
On 18/12/2020 14:33, James Szinger wrote: I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or are there going to be a lot of unhappy Firefox users? The bug is still open. From https://koji.fedoraproject.org/koji/buildinfo?buildID=1658942: * Tue Dec 15 2020 Bob Relyea - 3.59.0-3 - Back out strict SHA-1 signature control because firefox Addon system is still using sha-1 signatures Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, 15 Dec 2020 11:17:21 -0800 Kevin Fenzi wrote: > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > will stop working. Worse they will appear corrupted, so you will have > to remove them and re-install them (after downgrading nss). > > For now, downgrade nss or avoid updating to it until things can get > sorted out. > > https://bugzilla.redhat.com/show_bug.cgi?id=1908018 > > kevin I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or are there going to be a lot of unhappy Firefox users? The bug is still open. Thanks, Jim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 16, 2020 at 2:45 AM Miro Hrončok wrote: > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > == Scope == > > * Proposal owners: > > We will go through the Fedora release and determine what nodejs > > packages Fedora should package. We will implement nodejs library > > bundling on those we already own. For those that we do not own, we > > will work with their owners to implement nodejs library bundling. > > > > As packages implement nodejs library bundling, we will monitor the > > nodejs libraries and note which ones are no longer required. When > > they are no longer required, we will retire them, if we own them. If > > we do not own them, we will work with the owners to retire them, if > > they wish. > > > > * Other developers: > > For Fedora packagers whose package rely on nodejs libraries, please > > contact the > > [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > > Nodejs SIG]] and we will help you find the easiest way to bundle your > > nodejs libraries. > > > > For Fedora nodejs library packages, look to see what depends on your > > library. If it looks like you can do so, retire your nodejs library. > > If you would like, give the > > [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > > Nodejs SIG]] admin to your nodejs libraries, and they will work > > through the process for you. > > I thought about this a bit more and I would really appreciate to see at least > some preliminary list of packages that will be retired/removed (completely > fine > if it's defined as "all nodejs-* packages except subpackages of nodejs itself > and nodejs-packaging") and the *list of dependent packages that are impacted > by > this change*. > > I've done some preliminary check with: > > https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py > > $ python find_unblocked_orphans.py --skip-orphans $(repoquery > --repo=rawhide-source -a | pkgname | grep ^nodejs- | grep -v > ^nodejs-packaging$ > | sort | uniq) > > ... > > The following packages require above mentioned packages: > Depending on: nodejs-backbone (2), status change: 2017-08-04 (175 weeks ago) > beets (maintained by: maha, mbaldessari) > beets-plugins-1.4.9-8.fc33.noarch requires js-backbone = > 1.3.3-10.fc34 > > python-notebook (maintained by: churchyard, python-sig) > python3-notebook-6.1.4-1.fc34.noarch requires js-backbone = > 1.3.3-10.fc34 > > Depending on: nodejs-generic-pool (1), status change: 2020-08-24 (16 weeks > ago) > statsd (maintained by: noodles, piotrp) > statsd-0.8.6-1.fc34.noarch requires npm(generic-pool) = 2.2.2 > > Depending on: nodejs-shelljs (1), status change: 2020-05-13 (31 weeks ago) > notepadqq (maintained by: orphan) > notepadqq-1.4.8-13.fc33.x86_64 requires nodejs-shelljs = > 0.8.4-2.fc33 > > Depending on: nodejs-typescript (1), status change: 2020-11-22 (3 weeks ago) > gnome-shell-extension-pop-shell (maintained by: carlwgeorge, > dustymabe) > > gnome-shell-extension-pop-shell-1.0.0-3.20201130gitee943b8.fc34.src requires > npm(typescript) = 4.0.2 > > Depending on: nodejs-underscore (11), status change: 2020-05-13 (31 weeks ago) > R-V8 (maintained by: qulogic) > R-V8-3.4.0-1.fc34.src requires js-underscore = 1.10.2-3.fc34 > R-V8-3.4.0-1.fc34.x86_64 requires js-underscore = > 1.10.2-3.fc34 > > beets (maintained by: maha, mbaldessari) > beets-plugins-1.4.9-8.fc33.noarch requires js-underscore = > 1.10.2-3.fc34 > > coffee-script (maintained by: jsmith, nodejs-sig, patches, vjancik) > coffee-script-1.10.0-14.fc33.src requires npm(underscore) = > 1.10.2 > > python-f5-sdk (maintained by: xavierb) > python-f5-sdk-3.0.21-7.fc33.src requires js-underscore = > 1.10.2-3.fc34 > python-f5-sdk-doc-3.0.21-7.fc33.noarch requires js-underscore > = 1.10.2-3.fc34 > > python-h2 (maintained by: eclipseo, python-sig) > python-h2-4.0.0-1.fc34.src requires js-underscore = > 1.10.2-3.fc34 > python-h2-doc-4.0.0-1.fc34.noarch requires js-underscore = > 1.10.2-3.fc34 > > python-hyperlink (maintained by: eclipseo, python-sig) > python-hyperlink-20.0.1-1.fc34.src requires js-underscore = > 1.10.2-3.fc34 > python-hyperlink-doc-20.0.1-1.fc34.noarch requires > js-underscore = 1.10.2-3.fc34 > > python-notebook (maintained by: churchyard, python-sig) > python3-notebook-6.1.4-1.fc34.noarch requires js-underscore = > 1.10.2-3.fc34 > > perl-Mojolicious-Plugin-AssetPack (maintained by: eseyman) > perl-Mojolicious-Plugin-AssetPack-2.10-1.fc34.src requires > coffee-script = > 1.10.0-14.fc33 > > python-webassets (maintained by: dcallagh, kumarpraveen, pjp, > sundaram) >
[Bug 1909154] perl-ExtUtils-Install-2.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909154 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1909154] New: perl-ExtUtils-Install-2.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909154 Bug ID: 1909154 Summary: perl-ExtUtils-Install-2.20 is available Product: Fedora Version: rawhide Status: NEW Component: perl-ExtUtils-Install Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.20 Current version/release in rawhide: 2.18-1.fc34 URL: http://search.cpan.org/dist/ExtUtils-Install/ 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/15262/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Fedora rawhide compose report: 20201218.n.0 changes
OLD: Fedora-Rawhide-20201217.n.0 NEW: Fedora-Rawhide-20201218.n.0 = SUMMARY = Added images:0 Dropped images: 4 Added packages: 2 Dropped packages:2 Upgraded packages: 76 Downgraded packages: 1 Size of added packages: 2.92 MiB Size of dropped packages:4.33 MiB Size of upgraded packages: 1.58 GiB Size of downgraded packages: 292.27 KiB Size change of upgraded packages: 273.23 MiB Size change of downgraded packages: 1.50 KiB = ADDED IMAGES = = DROPPED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20201217.n.0-sda.raw.xz Image: Container_Minimal_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20201217.n.0.x86_64.tar.xz Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20201217.n.0-sda.raw.xz Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20201217.n.0-sda.raw.xz = ADDED PACKAGES = Package: golang-github-zmap-zlint-2-2.2.1-1.fc34 Summary: X.509 Certificate Linter focused on Web PKI standards and requirements RPMs:compat-golang-github-zmap-zlint-2-devel golang-github-zmap-zlint-2-devel Size:448.33 KiB Package: mingw-openexr-2.5.3-1.fc34 Summary: MinGW Windows openexr library RPMs:mingw32-openexr mingw32-openexr-tools mingw64-openexr mingw64-openexr-tools Size:2.48 MiB = DROPPED PACKAGES = Package: mingw-OpenEXR-2.4.1-3.fc33 Summary: MinGW Windows OpenEXR library RPMs:mingw32-OpenEXR mingw32-OpenEXR-static mingw32-OpenEXR-tools mingw64-OpenEXR mingw64-OpenEXR-static mingw64-OpenEXR-tools Size:3.52 MiB Package: mingw-ilmbase-2.4.1-2.fc33 Summary: MinGW Windows ilmbase library RPMs:mingw32-ilmbase mingw32-ilmbase-static mingw64-ilmbase mingw64-ilmbase-static Size:834.41 KiB = UPGRADED PACKAGES = Package: R-testthat-3.0.1-1.fc34 Old package: R-testthat-3.0.0-1.fc34 Summary: Unit Testing for R RPMs: R-testthat Size: 7.28 MiB Size change: 54.33 KiB Changelog: * Thu Dec 17 2020 Tom Callaway - 3.0.1-1 - update to 3.0.1 Package: Singular-4.1.1p3-22.fc34 Old package: Singular-4.1.1p3-21.fc34 Summary: Computer Algebra System for polynomial computations RPMs: Singular Singular-devel Singular-doc Singular-emacs Singular-libpolys Singular-libpolys-devel Singular-libs Singular-polymake Singular-surfex factory factory-devel factory-gftables Size: 107.63 MiB Size change: -16.54 KiB Changelog: * Thu Dec 17 2020 Jerry James - 4.1.1p3-22 - Rebuild for polymake 4.3 Package: adwaita-qt-1.2.0-1.fc34 Old package: adwaita-qt-1.1.90-1.fc34 Summary: Adwaita theme for Qt-based applications RPMs: adwaita-qt5 libadwaita-qt5 libadwaita-qt5-devel Size: 1.46 MiB Size change: -4.51 KiB Changelog: * Thu Dec 17 2020 Jan Grulich - 1.2.0-1 - 1.2.0 Package: ansible-2.9.16-1.fc34 Old package: ansible-2.9.15-1.fc34 Summary: SSH-based configuration management, deployment, and task execution system RPMs: ansible ansible-doc Size: 25.63 MiB Size change: -62.52 KiB Changelog: * Tue Dec 15 2020 Kevin Fenzi - 2.9.16-1 - Update to 2.9.16. Package: awscli-1.18.198-1.fc34 Old package: awscli-1.18.197-1.fc34 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.95 MiB Size change: 109 B Changelog: * Thu Dec 17 2020 Gwyn Ciesla - 1.18.198-1 - 1.18.198 Package: bind-dyndb-ldap-11.6-3.fc34 Old package: bind-dyndb-ldap-11.6-1.fc34 Summary: LDAP back-end plug-in for BIND RPMs: bind-dyndb-ldap Size: 536.61 KiB Size change: -9.03 KiB Changelog: * Thu Dec 17 2020 Alexander Bokovoy - 11.6-2 - Fix requires to bind: require bind installed before bind-dyndb-ldap as we depend on named group * Thu Dec 17 2020 Alexander Bokovoy - 11.6-3 - Both require bind and require it for pre-install script - Resolves: rhbz#1902811 Package: blitz-1.0.2-6.fc34 Old package: blitz-1.0.2-2.fc33 Summary: C++ class library for matrix scientific computing RPMs: blitz blitz-devel blitz-doc Size: 1.74 MiB Size change: -52.48 MiB Changelog: * Mon Jul 27 2020 Fedora Release Engineering - 1.0.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Aug 01 2020 Fedora Release Engineering - 1.0.2-4 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Tue Aug 18 2020 Sergio Pascual - 1.0.2-5 - Fix cmake out-of-source-build (bz #1863269) * Fri Dec 18 2020 Sergio Pascual - 1.0.2-6 - EVR bump to rebuild Package: callaudiod-0.0.4-2.fc34 Old package: callaudiod-0.0.4-1.fc34 Summary: Daemon for dealing with audio routing during phone calls RPMs: callaudiod callaudiod-devel Size: 340.06 KiB Size change: -178.34 KiB Changelog: * Thu Dec 17
Re: libQt5WebEngineCore.so: undefined reference to `PK11_SignatureLen@NSS_3.2'
On Fri, Dec 18, 2020 at 12:04:29PM +0100, Antonio T. sagitter wrote: > It's a problem (undefined references) inside the 'qt5-qtwebengine' package. > > On 18/12/20 10:01, Martin Gansser wrote: > >Hi, > > > >clipgrab fails to compile on rawhide with this error message [1]: > > > >/libQt5Network.so /usr/lib64/libQt5Xml.so /usr/lib64/libQt5Positioning.so > >/usr/lib64/libQt5Core.so -lGL -lpthread > >/usr/bin/ld: warning: libsmime3.so, needed by > >/usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or > >-rpath-link) > >/usr/bin/ld: warning: libnss3.so, needed by > >/usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or > >-rpath-link) > >/usr/bin/ld: warning: libnssutil3.so, needed by > >/usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or > >-rpath-link) > >/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so: undefined reference to > >`PK11_SignatureLen@NSS_3.2' > >/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so: undefined reference to > >`PORT_Strdup@NSS_3.5' > > > >[1] https://koji.rpmfusion.org/kojifiles/work/tasks/2478/452478/build.log > > > >how can i solve this ? It's caused by firefox most likely https://bugzilla.redhat.com/show_bug.cgi?id=1908018#c12 I used the following work-around: https://src.fedoraproject.org/rpms/geeqie/c/70877540539d3592e583ddc14cdcf8edfb468ee6?branch=master 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
[Test-Announce] Fedora 34 Rawhide 20201218.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 34 Rawhide 20201218.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 Notable package version changes: lorax - 20201215.n.0: lorax-34.5-1.fc34.src, 20201218.n.0: lorax-34.6-1.fc34.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/34 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_34_Rawhide_20201218.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201218.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201218.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201218.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201218.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201218.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201218.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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to troubleshoot aarch64 and s390x?
On Thu, Dec 17, 2020 at 4:07 PM Sérgio Basto wrote: > On Thu, 2020-12-17 at 07:32 -0600, Richard Shaw wrote: > > I'm working on building the new openexr package but the unit tests are > failing but just on aarch64 and s390x. > > > Since is testing building, wh not mock with forcearch [1] ? > Well, it only took a little over 5 hours for one build attempt, but it worked! And that was on my decent desktop machine AMD Ryzen 5 3600. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
Dne pá 18. 12. 2020 10:52 dop. uživatel Miro Hrončok napsal: > On 12/18/20 1:19 AM, clime wrote: > >> I'd very much like to understand the impact of this on the following: > >> > >> > >> 1) Provenpackagers doing mass spec changes/updates. > > If the mass spec change/update doesn't involve an rpkg macro, then > > there is no difference. > > I don't understand how there is no difference. The spec "bare" spec file > is no > longer there. How do I parse it? How do I grep it? How do I sed it? > But the spec template is there. And the template can be modified. You can grep it and sed it, you cannot directly parse it with rpm without preprocessing it first. > >> 2) Provenpackagers and/or RelEngs doing (targeted) mass rebuilds. > > There should be no impact here. If the source git repo stays the same, > > then the same srpm as for a previous build will be produced. > > I don't understand you answer. What does this have to do with "source git > repo > stays the same" and "same srpm"? The release must be bumped, they are not > the same. > Yes, you are right. I was thinking along the lines of a feature that doesn't exist, which is inserting buildID into built rpms (not srpms) and making that an effective part of the full resulting rpm name. But there is nothing like that. Sorry for that. Release needs to be bumped even for soname-bump rebuilds (at least nowadays) so there is an impact if the target package uses git_dir_release preprocessing macro. In that case, bumping is done either by creating a new commit or a new annotated tag (the new tag will also add a new changelog entry and will make the release look nicer). Basically, if releng/ProvenPackager does a rebuild of a package manually, the recommended action currently for such a package is to add a new annotated tag (`fedpkg tag`) and write the reason for the rebuild. If a script is used, that script can be modified to automatically recognize if the target package uses the rpkg macro or not and do the required action for bumping accordingly. This is kind of a logic that should land in rpmdev-bumpspec. If this seems inconvenient, we can further discuss the options. We could e.g. make it so that just creating a new empty commit would be enough instead of tagging. > Thanks for the other answers. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libQt5WebEngineCore.so: undefined reference to `PK11_SignatureLen@NSS_3.2'
It's a problem (undefined references) inside the 'qt5-qtwebengine' package. On 18/12/20 10:01, Martin Gansser wrote: Hi, clipgrab fails to compile on rawhide with this error message [1]: /libQt5Network.so /usr/lib64/libQt5Xml.so /usr/lib64/libQt5Positioning.so /usr/lib64/libQt5Core.so -lGL -lpthread /usr/bin/ld: warning: libsmime3.so, needed by /usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libnss3.so, needed by /usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libnssutil3.so, needed by /usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so: undefined reference to `PK11_SignatureLen@NSS_3.2' /usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so: undefined reference to `PORT_Strdup@NSS_3.5' [1] https://koji.rpmfusion.org/kojifiles/work/tasks/2478/452478/build.log how can i solve this ? Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x29FBC85D7A51CC2F GPG key server: https://keys.gnupg.net/ OpenPGP_0x29FBC85D7A51CC2F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On 12/18/20 12:57 AM, Matthew Miller wrote:
On Fri, Dec 18, 2020 at 12:24:10AM +0100, clime wrote:
It would be possible to specify the spec template as an rpm Source so
it would get included into the resulting srpm as well.
Yeah I was thinking the spec file templating system could automatically add
the original spec as Source where N is one higher than the highest
existing source file.
If that's automatically happening, it could produce undesired results with the
%{sources} macro.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On 12/18/20 1:19 AM, clime wrote: I'd very much like to understand the impact of this on the following: 1) Provenpackagers doing mass spec changes/updates. If the mass spec change/update doesn't involve an rpkg macro, then there is no difference. I don't understand how there is no difference. The spec "bare" spec file is no longer there. How do I parse it? How do I grep it? How do I sed it? 2) Provenpackagers and/or RelEngs doing (targeted) mass rebuilds. There should be no impact here. If the source git repo stays the same, then the same srpm as for a previous build will be produced. I don't understand you answer. What does this have to do with "source git repo stays the same" and "same srpm"? The release must be bumped, they are not the same. Thanks for the other answers. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20201218.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20201217.0): ID: 743480 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/743480 ID: 743487 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/743487 Passed openQA tests: 6/7 (x86_64), 6/7 (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
Problems upgrading to f33 cloud edition
Hi, sorry for posting here if this is not correct. I'm upgraing a f32 cloud edition to f33 and I found this problem which I can't solve: $ sudo dnf system-upgrade --releasever 33 --skip-broken --allowerasing -vvv download I get this response: Error: Problem: conflicting requests - package console-login-helper-messages-issuegen-0.20.3-1.fc33.noarch requires NetworkManager, but none of the providers can be installed - package console-login-helper-messages-issuegen-0.20.1-1.fc33.noarch requires NetworkManager, but none of the providers can be installed I don't have console-login-helper-messages installed in f32. Thanks for you help Guido Aulisi 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
Re: Chromium built in rawhide does not render most strings
Am 17.12.20 um 17:12 schrieb Tom Callaway: Okay, this one has me stumped. Any chromium package I build through rawhide refuses to render most of the strings. Afaik chromium can't access libva anymore. On the pinephone, where i noticed this bug, it said so itself. Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On Friday, 18 December 2020, Tom Stellard wrote: > On 12/17/20 11:05 AM, Ben Cotton wrote: > >> https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing >> >> >> == Summary == >> This change should enable an opt-in spec file preprocessor in Fedora >> infrastructure for the benefit of packagers. The preprocessor allows >> some very neat tricks that were impossible before, for example >> generate changelog and release automatically from git metadata or pack >> the entire dist-git repository into an rpm-source tarball (effectively >> allowing unpacked repos to live in DistGit). >> >> == Owner == >> * Name: [[User:clime| Michal Novotný]] >> * Email: cl...@fedoraproject.org >> >> >> == Detailed Description == >> >> There is a recently added feature into mock: >> [https://github.com/rpm-software-management/mock/wiki/Plugin >> -rpkg-preprocessor >> the rpkg preprocessor] which, if enabled, introduces an intermediate >> step just before srpm building. This step consists of running the spec >> file through a text preprocessing engine that includes an already >> present library of macros designed specifically for rpm spec file >> generation from git metadata. This library is called >> [https://docs.pagure.org/rpkg-util/v3/macro_reference.html >> rpkg-macros]. The macros there allow packagers to have their >> `%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields >> automatically generated from dist-git repository data and metadata. >> The library can be easily extended in future to support more packager >> use-cases or even a completely new library can be developed that >> doesn't look at git metadata at all and instead, for example, analyses >> already present tarball content to render spec file based on upstream >> information. This doesn't mean it will happen but the framework is >> generic enough to support that. There is also support for user-defined >> macros that are loaded on-demand from a file placed alongside the >> package sources, maintained by packager. This feature wouldn't be >> enabled by this change from start but it's an example of freedom that >> the preprocessing framework is able to provide. Enabling this change >> should be very easy, basically adding: >> >> >> config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True >> >> >> into mock configuration of Koji builders and using at least mock 2.7. >> Some very minor change may be also needed in Koji regarding the spec >> file lookup. >> >> Even if the change is enabled on the infrastructure level like this, >> the packager will still need to opt-in to use the preprocessor. The >> opting-in is done by placing `rpkg.conf` file into the package >> top-level directory with the following content: >> >> >> [rpkg] >> preprocess_spec = True >> >> >> When this is done by a packager, the preprocessor will be finally >> enabled for the given package. >> >> Alongside, there is an ongoing work to add the preprocessor support >> into the `rpkg` python library so that a packager can easily work with >> the spec files containing the preprocessor (rpkg) macros: >> https://pagure.io/rpkg/pull-request/530 >> >> > Is this pull request needed so that the preprocessor will run if I do > `fedpkg mockbuild` or does fedpkg already do this if the preprocessor is > enabled? The pull request is needed for it. fedpkg doesn't currently have support for preprocessing. Cheers clime > > -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.or > g/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
libQt5WebEngineCore.so: undefined reference to `PK11_SignatureLen@NSS_3.2'
Hi, clipgrab fails to compile on rawhide with this error message [1]: /libQt5Network.so /usr/lib64/libQt5Xml.so /usr/lib64/libQt5Positioning.so /usr/lib64/libQt5Core.so -lGL -lpthread /usr/bin/ld: warning: libsmime3.so, needed by /usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libnss3.so, needed by /usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libnssutil3.so, needed by /usr/lib64/libQt5WebEngineCore.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so: undefined reference to `PK11_SignatureLen@NSS_3.2' /usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so: undefined reference to `PORT_Strdup@NSS_3.5' [1] https://koji.rpmfusion.org/kojifiles/work/tasks/2478/452478/build.log how can i solve this ? Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
