Re: Donate 1 minute of your time to test upgrades from F30 to F31
On Fri, Sep 13, 2019 at 07:33:17AM +0200, Julian Sikorski wrote: > Problem 1: conflicting requests > > - nothing provides module(platform:f30) needed by module > eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64 > > Problem 2: module jmc:latest:3120190813124555:7188e41a-0.x86_64 > requires module(eclipse), but none of the providers can be installed > > - conflicting requests > > - nothing provides module(platform:f30) needed by module > eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64 > > > what should I file the bug against? > > Błąd: > > Problem 1: package banshee-2.6.2-34.fc31.x86_64 requires > mono(gudev-sharp) = 1.0.0.0, but none of the providers can be installed > > - problem with installed package banshee-2.6.2-32.fc30.x86_64 > > - gudev-sharp-1:0.1-25.fc30.x86_64 does not belong to a distupgrade > repository > > - banshee-2.6.2-32.fc30.x86_64 does not belong to a distupgrade repository > > > should I file the bug against banshee, or against > fedora-obsolete-packages? Banshee appears to be as good as dead upstream. banshee is still maintained in Fedora. It seems that latest banshee package requires mono(Mono.Addins) = 1.0.0.0, but mono-addins only provides mono(Mono.Addins) = 0.6.0.0. Maybe we need a later version? > Problem 2: problem with installed package > system-config-users-docs-1.0.9-14.fc30.noarch > > - package system-config-users-docs-1.0.9-15.fc31.noarch requires > system-config-users >= 1.2.82, but none of the providers can be installed > > - system-config-users-docs-1.0.9-14.fc30.noarch does not belong to a > distupgrade repository > > - system-config-users-1.3.8-6.fc29.noarch does not belong to a > distupgrade repository > > > This was already reported against fedora-obsolete-packages https://bugzilla.redhat.com/show_bug.cgi?id=1751241 https://bugzilla.redhat.com/show_bug.cgi?id=1751252 Waiting for a reply here. 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
Re: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)
Le 2019-09-13 00:05, Kevin Kofler a écrit : Marius Schwarz wrote: (in short: no update to 2.00.5-3 was possible via dnf, as packages refer to 2.00.3-1 directly) They don't actually refer to liberation-fonts-2.00.3-1, but to liberation- narrow-fonts, which liberation-fonts-2.00.3-1 claims to Provide, but does not actually provide. The correct thing would have been never to create a narrow liberation subpackage in the first place since narrow is just a face of a font (like bold). Mid term, all of those should switch to a liberation sans requires (via font(liberationsans) not explicit package name) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Self Introduction: rufo
Hello, Rufus! Welcome to Fedora. On Wednesday, 11 September 2019 at 00:16, rufo via devel wrote: > Hi everyone, > > My name is Rufus and I'm a developer from the UK. I'm just beginning my > journey into Fedora packaging, although I've been a happy end-user since the > days of Red Hat 9. > > I'm currently learning about the packaging process and guidelines, so I can > better contribute to a couple of existing packages I use which need some > help. In time, perhaps I will be able to submit new packages of my own which > would benefit Fedora users. I look forward to becoming more proficient and > being sponsored into the `packager` group. You're joining at a pretty busy time. Fedora is in Beta Freeze in preparation for Fedora 31 Beta: https://fedoraproject.org/wiki/Releases/31/Schedule I'd suggest trying to do a couple of package reviews to have something to show to your sponsor. You can pick some from the queue: https://fedoraproject.org/PackageReviewStatus/ Here's the review process: https://fedoraproject.org/wiki/Package_Review_Process Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)
Nicolas Mailhot via devel wrote: > The correct thing would have been never to create a narrow liberation > subpackage in the first place since narrow is just a face of a font > (like bold). In theory, in an ideal world, that makes sense. But in practice, M$ ships separate "Arial" and "Arial Narrow" fonts which are used in that form in thousands of documents worldwide, and we need to be compatible with that. So there need to be 2 separate fonts. And the reason why the 2 Liberation Sans variants (plain and Narrow) are now in separate packages is that Liberation 2 does not ship Liberation Sans Narrow anymore, because it is not part of the set of fonts Google bought. (Liberation 2 is a fork of the Google Croscore fonts.) It was part of the set of fonts Red Hat bought for Liberation 1 though, so we ship Liberation Sans Narrow from Liberation 1 as a separate package under a different license. So there are valid technical and legal reasons for the subpackage to be separate. Hence, this is not likely to change any time soon. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
mock -r fedora-31-i386 broken
Hi, Apparently mock-build roots for fedora-31-i386 currently are broken: # mock -r fedora-31-i386 --init INFO: mock.py version 1.4.16 starting (python version = 3.7.4)... Start: init plugins INFO: selinux disabled Finish: init plugins Start: run Start: clean chroot Finish: clean chroot Start: chroot init INFO: calling preinit hooks INFO: enabled root cache INFO: enabled dnf cache Start: cleaning dnf metadata Finish: cleaning dnf metadata INFO: enabled HW Info plugin Mock Version: 1.4.16 INFO: Mock Version: 1.4.16 Start: dnf install No matches found for the following disable plugin patterns: local, spacewalk fedora 220 kB/s | 54 kB 00:00 Failed to download metadata for repo 'fedora' Error: Failed to download metadata for repo 'fedora' ERROR: Command failed: # /usr/bin/dnf --installroot /var/lib/mock/fedora-31-i386/root/ --releasever 31 --setopt=deltarpm=False --disableplugin=local --disableplugin=spacewalk install @buildsys-build No matches found for the following disable plugin patterns: local, spacewalk fedora 220 kB/s | 54 kB 00:00 Failed to download metadata for repo 'fedora' Error: Failed to download metadata for repo 'fedora' Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 31 System-Wide Change proposal (late): No i686 Repositories
On 9/13/19 1:38 AM, vvs vvs wrote: But there should be some reason for that lack of interested volunteers in Fedora. Right now I'm looking at stats for other distributions which are not going to drop i686 any time soon, e.g. Debian, NixOS, Gentoo. There must me some very fundamental difference with how they operate. Maybe in other distros, people interested in i686 support actually do something about it instead of talking and talking and talking about it on mailing lists? - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)
Le 2019-09-13 10:39, Kevin Kofler a écrit : Nicolas Mailhot via devel wrote: The correct thing would have been never to create a narrow liberation subpackage in the first place since narrow is just a face of a font (like bold). In theory, in an ideal world, that makes sense. But in practice, M$ ships separate "Arial" and "Arial Narrow" fonts which are used in that form in thousands of documents worldwide, and we need to be compatible with that. That's an historical artefact, that made sense when everyone used the same dozen font on windows, and when each and everyone of them could be treated as a special case. Nowadays, even on Linux (what a change a decade made) the font catalog is huge, and font processing *MUST* be generic to scale. So there need to be 2 separate fonts. No, what we need is to have a narrow set of liberation sans faces installed with the rest of the liberation sans. That's not the same thing as enshrining windows 95 style ways of deploying fonts. (windows 95 was engineered around truetype limitations which have been solved in opentype a long time ago; modern truetype is opentype). And the reason why the 2 Liberation Sans variants (plain and Narrow) are now in separate packages is that Liberation 2 does not ship Liberation Sans Narrow anymore, because it is not part of the set of fonts Google bought. And nothing prevents either using a src.rpm with two sources, or making a liberations-sans-narrow that supplements the base liberation-sans package, or making liberation-sans-fonts depend directly on liberation-sans-narrow > version. All of which result in a working standard generic font(liberationsans) dep. Point being, apps should not hardcode in their deps a specific liberation package split, just require font(liberationsans) like for any other font family, and let the people in charge of liberation deal with liberation internals, without leaking those internals right and left. The reason we have this breakage right now is that people though they needn't bother applying a generic font model, that it would be simpler to use legacy shortcuts, and that failed hard when liberation moved to 2. Which, should have been none of the app business in the first place. And restoring the legacy shortcuts does not help mid and long term. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Orphaned itext, plan is to retire it in ~2 weeks
On 03. 09. 19 18:47, Miro Hrončok wrote: I've just orphaned itext, previously owned the Stewardship SIG. The package wasn't updated for over a decade and has an open CVE from Fedora 26 era. The Stewardship SIG took it for maven-doxia, but we've luckily managed to get rid of the dependency. Since this package is dangerous, I'd like to retire it right away, but flyingsaucer requires it. Hence I plan to retire it once flyingsaucer is retired (it is already orphaned for 5 weeks). Retired. -- 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 31 System-Wide Change proposal (late): No i686 Repositories
> Maybe in other distros, people interested in i686 support actually do > something about it instead of talking and talking and talking about it > on mailing lists? Maybe someone with so much free time on their hands could maintain such a kernel in Fedora by applying downstream packages of such a distro. That person'd need to find a distribution that goes at least as fast Fedora when it comes to upgrading kernel packages... I very much doubt we'll find one we could rely on. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Possibly unresponsive maintainer: vakwetu
On Tue, Jul 9, 2019 at 8:17 PM Fabio Valentini wrote: > > On Tue, Jul 9, 2019 at 7:51 PM Dinesh Prasanth Moluguwan > Krishnamoorthy wrote: > > > > Hello everyone, > > > > As Rob had responded earlier, he is away for few weeks. A while back, I > > spoke to him in person about handing over the RESTeasy packages to the > > Fedora SIG. He had agreed to it. Once he is back, I will remind him to > > transfer those packages to the SIG. > > > > PS: Dogtag PKI depends on those RESTeasy packages. > > I know, which is why I am interested in fixing it (it's currently > broken in rawhide). Just a quick update: After two more months, the package has still not been touched (since 2016), and it is still broken on fedora 31+. Fabio > Fabio > > > Regards, > > --Dinesh > > > > > > On Tue, 2019-07-09 at 10:16 -0400, Rob Crittenden wrote: > > > Miro Hrončok wrote: > > > > On Tue, Jul 9, 2019 at 3:26 PM Rob Crittenden > > > > wrote: > > > > > He's on PTO for a few weeks. > > > > > > > > I wonder how valid this remark is when he has not responded in > > > > years. > > > > > > > > > > I can't speak to his previous work as a maintainer that but I have > > > personal knowledge that he is away. I'll otherwise take your comment > > > in > > > the most excellent way and not assume you are questioning my > > > truthfulness. > > > > > > rob > > > ___ > > > devel mailing list -- devel@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > > https://docs.fedoraproject.org/en-US/project/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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)
Nicolas Mailhot via devel wrote: > That's an historical artefact, that made sense when everyone used the > same dozen font on windows, and when each and everyone of them could be > treated as a special case. Nowadays, even on Linux (what a change a > decade made) the font catalog is huge, and font processing *MUST* be > generic to scale. But the fonts shipped with M$ Windows or M$ Office are still by far the most widely used. And those are referenced as "Arial" and "Arial Narrow". So we NEED separate Liberation Sans and Liberation Sans Narrow fonts that can be used as drop-in font substitutes for these. >> So there need to be 2 separate fonts. > > No, what we need is to have a narrow set of liberation sans faces > installed with the rest of the liberation sans. That's not the same > thing as enshrining windows 95 style ways of deploying fonts. (windows > 95 was engineered around truetype limitations which have been solved in > opentype a long time ago; modern truetype is opentype). No, sorry. We need to be compatible with existing documents and (in the case of WINE) applications. This is the whole point of the Liberation fonts. And this is only the technical part, there is also a legal issue: > And nothing prevents either using a src.rpm with two sources, or making > a liberations-sans-narrow that supplements the base liberation-sans > package, or making liberation-sans-fonts depend directly on > liberation-sans-narrow > version. All of which result in a working > standard generic font(liberationsans) dep. Liberation 1 and Liberation 2 are under different, incompatible licenses. It would be illegal to merge the 2 fonts into a single font. The only legal way to merge the fonts would be to stick to Liberation 1 for Liberation Sans too, which the Liberation team does not want to do for various reasons. > Point being, apps should not hardcode in their deps a specific > liberation package split, just require font(liberationsans) like for any > other font family, and let the people in charge of liberation deal with > liberation internals, without leaking those internals right and left. > > The reason we have this breakage right now is that people though they > needn't bother applying a generic font model, that it would be simpler > to use legacy shortcuts, and that failed hard when liberation moved to > 2. Which, should have been none of the app business in the first place. > And restoring the legacy shortcuts does not help mid and long term. This is absolutely wrong. The reason we have this breakage right now is because somebody decided that liberation-fonts should Obsolete and Provide liberation-narrow-fonts without actually providing that font. That it is a narrow variant of Liberation Sans is entirely irrelevant, it could have been called Fred or Foo and it would still be the same issue. A package should NEVER claim to Obsolete and Provide foo-fonts if it does not actually contain the font Foo. In addition, the Obsoletes was versioned in a ridiculous way, as < 1:2.0, when there was never such a version of liberation-narrow-fonts (it did not even have an Epoch). So bumping over the Obsoletes required bumping the Epoch from unspecified (0) to 2 (because the Version is still 1.x and will remain so for the foreseeable future, because Liberation 2 does NOT include this font). And finally, unlike the old YUM, DNF also processes Obsoletes from old versions of packages in the GA repositories, so an update can no longer safely withdraw an Obsoletes. This is a DNF issue and we need a solution in DNF, but the DNF developers refuse to acknowledge this as a bug in DNF. And since Liberation Sans Narrow is a different font, the applications would need to require font(liberationsansnarrow), not font(liberationsans), and so they would still be hit by the Obsoletes mess (because only liberation-narrow-fonts actually provides that). Again, your ideal world in which narrow is a natively supported property of a merged font is NOT the world we live in! At least not now. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Logs from Open NeuroFedora team meeting: 1500 UTC on Thursday, 12th September
Hello, Here are the logs from yesterday's meeting: HTML minutes: https://meetbot.fedoraproject.org/fedora-neuro/2019-09-12/neurofedora.2019-09-12-15.01.html HTML logs: https://meetbot.fedoraproject.org/fedora-neuro/2019-09-12/neurofedora.2019-09-12-15.01.log.html The text minutes are pasted below for your convenience. The next meeting will be held at the same time next Thursday. Meeting summary --- * Introductions and Roll call (mhough, 15:02:15) * Meetbot command reference: https://fedoraproject.org/wiki/Meeting:Guide#MeetBot_Commands (FranciscoD, 15:04:29) * Today's agenda (mhough, 15:07:23) * Tasks from last week's meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2019-09-05-14.59.html (mhough, 15:08:43) * Open bugs at: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=neuro-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emaildocs_contact1=1&emaillongdesc1=1&emailqa_contact1=1&emailreporter1=1&emailtype1=substring&list_id=10455921&query_format=advanced (mhough, 15:10:54) * Review of current progress (mhough, 15:11:25) * Action items from previous meeting (mhough, 15:12:02) * Neuroscience query of the week (mhough, 15:12:23) * Next meeting chair selection (mhough, 15:12:34) * Open floor (mhough, 15:12:44) * Tasks from last week's meeting (mhough, 15:13:56) * LINK: https://pagure.io/neuro-sig/NeuroFedora/issue/198 has been updated. (dan1mal, 15:15:30) * LINK: https://paste.fedoraproject.org/paste/tg2z27oYg5EL3FO159uF-w -> our additions (FranciscoD, 15:17:29) * LINK: https://paste.fedoraproject.org/paste/a4~V9ixFH7y9UqzN3OLNUg (FranciscoD, 15:20:34) * making a neurofedora groups package for installer (mhough, 15:20:51) * ACTION: FranciscoD look at F30 comps, update, open comps PR (FranciscoD, 15:25:25) * ACTION: dan1mal look at F30 comps, update, open comps PR (FranciscoD, 15:25:32) * issues with the labs image https://pagure.io/neuro-sig/NeuroFedora/issue/199 (mhough, 15:27:16) * Change proposal draft is here: https://fedoraproject.org/wiki/Changes/Comp_Neuro_Lab (FranciscoD, 15:27:30) * ACTION: FranciscoD make same additions to f30 and f31 for comps PR (FranciscoD, 15:28:26) * ACTION: dan1mal to edit webpage/userpage (dan1mal, 15:30:47) * ACTION: FranciscoD submit change proposal on Monday, 16th Sept (FranciscoD, 15:32:36) * review and merge biosig PR (mhough, 15:34:13) * update bug link on blog and docs with short link (mhough, 15:35:06) * short bug link: https://tinyurl.com/neurofedora-bugs (FranciscoD, 15:35:29) * comment on https://bugzilla.redhat.com/show_bug.cgi?id=1739786 (mhough, 15:35:32) * update of python3-fsleyes to fc30, fc31 (mhough, 15:37:23) * Please test python3-fsleyes, and if it works, please give this update +1 karma: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d10d453d2b (FranciscoD, 15:39:21) * LINK: https://bodhi.fedoraproject.org/updates/?packages=sip (FranciscoD, 15:41:55) * F31 fsleyes + sip + wxpython update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e58677d9dd (FranciscoD, 15:42:25) * additonal pagure tickets (mhough, 15:44:35) * #276 Package descriptions (mhough, 15:45:29) * Infra ticket to update package summaries: https://pagure.io/fedora-infrastructure/issue/8159 (FranciscoD, 15:46:05) * #274 Flock conference reports (mhough, 15:46:13) * #250 (mhough, 15:48:13) * ACTION: FranciscoD write event report for OSB workshop (FranciscoD, 15:48:49) * Neuroscience query of the week (mhough, 15:52:31) * http://www.opensourcebrain.org/docs/Help/Meetings#OSB_2019 -> was the agenda (FranciscoD, 15:53:31) * From the experimental side, "Neurodata without borders" is now quite widely accepted: https://neurodatawithoutborders.github.io/ (FranciscoD, 15:57:02) * LINK: https://researcher.watson.ibm.com/researcher/view.php?person=us-gcecchi (mhough, 16:01:39) * LINK: http://www.crm.umontreal.ca/2018/MAIN2018/index_e.php (mhough, 16:04:38) * LINK: https://portal.brain-map.org/ -> massive database of neurons (FranciscoD, 16:05:40) * Next meeting day, and chair. (mhough, 16:06:27) * FranciscoD chair next meeting (FranciscoD, 16:09:00) * ACTION: mhough send out logs to mailing list (FranciscoD, 16:09:35) Meeting ended at 16:10:05 UTC. Action Items * FranciscoD look at F30 comps, update, open comps PR * dan1mal look at F30 comps, update, open comps PR * FranciscoD make same additions to f30 and f31 for comps PR * dan1mal to edit webpage/userpage * FranciscoD submit change proposal on Monday, 16th Sept * FranciscoD write event report for OSB workshop * mhough send out logs to mailing list Action Items, by person --- * dan1mal * dan1mal look at F30 comps, update, open comps PR * dan1mal to edit webpage/
Re: Donate 1 minute of your time to test upgrades from F30 to F31
Dne 11. 09. 19 v 17:04 Solomon Peachy napsal(a): > There are a couple > of F29 stragglers left behind from the last upgrade too. Not sure what > I should file tickets about here.. There is `dnf autoremove`. You should try that. Vít 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
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Le ven. 13 sept. 2019 à 11:44, Dridi Boukelmoune a écrit : > > > Maybe in other distros, people interested in i686 support actually do > > something about it instead of talking and talking and talking about it > > on mailing lists? > > Maybe someone with so much free time on their hands could maintain > such a kernel in Fedora by applying downstream packages of such a > distro. Well... I don't qualify as a person with much free time but... I'm toying with kernel-longterm in a copr for .4.19 branch, and I've enabled i686 there. The rebuilt is a semi-automated way. This i686 build is totally untested, please send patch along to report any issue (or report upstream if relevant). https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.19/ Best regards. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Possibly unresponsive maintainer: vakwetu
On 13. 09. 19 12:05, Fabio Valentini wrote: On Tue, Jul 9, 2019 at 8:17 PM Fabio Valentini wrote: On Tue, Jul 9, 2019 at 7:51 PM Dinesh Prasanth Moluguwan Krishnamoorthy wrote: Hello everyone, As Rob had responded earlier, he is away for few weeks. A while back, I spoke to him in person about handing over the RESTeasy packages to the Fedora SIG. He had agreed to it. Once he is back, I will remind him to transfer those packages to the SIG. PS: Dogtag PKI depends on those RESTeasy packages. I know, which is why I am interested in fixing it (it's currently broken in rawhide). Just a quick update: After two more months, the package has still not been touched (since 2016), and it is still broken on fedora 31+. I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1751976 Does anyone knows how to contact the maintainer? Links to all other bug reports open on resteasy: https://bugzilla.redhat.com/show_bug.cgi?id=1736585 (FTBFS) https://bugzilla.redhat.com/show_bug.cgi?id=1372118 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1372122 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1372125 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1372130 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1404912 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1456313 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1471273 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1471275 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1471277 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1471279 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1480769 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1481780 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1539175 (CVE) https://bugzilla.redhat.com/show_bug.cgi?id=1590941 (CVE) -- 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: Donate 1 minute of your time to test upgrades from F30 to F31
On Fri, Sep 13, 2019 at 12:48:44PM +0200, Vít Ondruch wrote: > > There are a couple > > of F29 stragglers left behind from the last upgrade too. Not sure what > > I should file tickets about here.. > > There is `dnf autoremove`. You should try that. Hate to state the obvious, but blindly removing packages (and anything that depends on them) is probably not the correct thing to do. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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: mock -r fedora-31-i386 broken
Just FTR, this was brought up already: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2V2RRTT7DTHWANFHL6YBVM7RILCWDGGT/ Vít Dne 13. 09. 19 v 10:38 Ralf Corsepius napsal(a): > Hi, > > Apparently mock-build roots for fedora-31-i386 currently are broken: > > # mock -r fedora-31-i386 --init > INFO: mock.py version 1.4.16 starting (python version = 3.7.4)... > Start: init plugins > INFO: selinux disabled > Finish: init plugins > Start: run > Start: clean chroot > Finish: clean chroot > Start: chroot init > INFO: calling preinit hooks > INFO: enabled root cache > INFO: enabled dnf cache > Start: cleaning dnf metadata > Finish: cleaning dnf metadata > INFO: enabled HW Info plugin > Mock Version: 1.4.16 > INFO: Mock Version: 1.4.16 > Start: dnf install > No matches found for the following disable plugin patterns: local, > spacewalk > fedora 220 kB/s | 54 kB 00:00 > Failed to download metadata for repo 'fedora' > Error: Failed to download metadata for repo 'fedora' > ERROR: Command failed: > # /usr/bin/dnf --installroot /var/lib/mock/fedora-31-i386/root/ > --releasever 31 --setopt=deltarpm=False --disableplugin=local > --disableplugin=spacewalk install @buildsys-build > No matches found for the following disable plugin patterns: local, > spacewalk > fedora 220 kB/s | 54 kB 00:00 > Failed to download metadata for repo 'fedora' > Error: Failed to download metadata for repo 'fedora' > > > Ralf > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
hypre licence change
I'm preparing an update for hypre which has a licence change from LGPLv2 to MIT or ASL 2.0. It is required by petsc and sundials. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Donate 1 minute of your time to test upgrades from F30 to F31
Dne 13. 09. 19 v 13:30 Solomon Peachy napsal(a): > On Fri, Sep 13, 2019 at 12:48:44PM +0200, Vít Ondruch wrote: >>> There are a couple >>> of F29 stragglers left behind from the last upgrade too. Not sure what >>> I should file tickets about here.. >> There is `dnf autoremove`. You should try that. > Hate to state the obvious, but blindly removing packages (and anything > that depends on them) is probably not the correct thing to do. That is much better option than using `--allowerasing`, because this command removes leaf packages, on which nothing depends. Of course you are in charge if the packages are removed at the end or not. Using f-o-p is not always better, because obviously if nothing else, somebody must maintain that package. Vít > > - Solomon > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: 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: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)
Le vendredi 13 septembre 2019 à 12:18 +0200, Kevin Kofler a écrit : > Nicolas Mailhot via devel wrote: > > That's an historical artefact, that made sense when everyone used > > the > > same dozen font on windows, and when each and everyone of them > > could be > > treated as a special case. Nowadays, even on Linux (what a change a > > decade made) the font catalog is huge, and font processing *MUST* > > be > > generic to scale. > > But the fonts shipped with M$ Windows or M$ Office are still by far > the most > widely used. And those are referenced as "Arial" and "Arial Narrow". So what ? We will never display Arial and Arial Narrow for trademark reasons. What you see in font lists is not what is declared in the files themselves (first, because font files have several layers of naming, second, because both Linux and Windows rewrite what the font files declare, except for very very old legacy windows programs that are so dumb they use the raw values of the most obsolete and legacy layer of font naming; those programs will fail with Liberation any version because no Liberation font file was ever tagged with Arial within itself for legal reasons). We do not need to slavishly copy font list artefact in package naming (that's why apache is in a package named httpd) And so on. > So we > NEED separate Liberation Sans and Liberation Sans Narrow fonts that > can be > used as drop-in font substitutes for these. > > > > So there need to be 2 separate fonts. > > > > No, what we need is to have a narrow set of liberation sans faces > > installed with the rest of the liberation sans. That's not the same > > thing as enshrining windows 95 style ways of deploying fonts. > > (windows > > 95 was engineered around truetype limitations which have been > > solved in > > opentype a long time ago; modern truetype is opentype). > > No, sorry. We need to be compatible with existing documents and (in > the case > of WINE) applications. This is the whole point of the Liberation > fonts. You're conflating package naming with font lists, and you're assuming fonts files have a single naming layer, when all opentype formats provide several layers of legacy naming to accomodate legacy apps. There's zip reason for the Fedora package naming and split to be built around legacy layers of naming and to force every single Fedora app to use windows 95 conventions. And even if the font files didn't include several layers of legacy naming, that's what fontconfig aliasing exists for. Your apps are using fontconfig aliasing since that's what tells them Arial is really Liberation Sans on Linux systems; the mecanism in fontconfig to tell apps Arial Narrow + Bold Italic is really Liberation Sans + Narrow Bold Italic, is exactly the same than to tell apps Arial Narrow + Bold Italic is really Liberation Sans Narrow + Bold Italic The font files can and do declare both Liberation Sans + Narrow Bold Italic and Liberation Sans Narrow + Bold Italic at different layers of opentype naming; you're only seing one of those in GUI font lists because there is not point of drowning users in font aliases, so apps choose one to display, and work with all of them internally. The legacy way of declaring Liberation Sans + Narrow Bold is actually forbidden by the opentype standard in its most recent layer of naming. > > And this is only the technical part, there is also a legal issue: > > > And nothing prevents either using a src.rpm with two sources, or > > making > > a liberations-sans-narrow that supplements the base liberation-sans > > package, or making liberation-sans-fonts depend directly on > > liberation-sans-narrow > version. All of which result in a working > > standard generic font(liberationsans) dep. > > Liberation 1 and Liberation 2 are under different, incompatible > licenses. It > would be illegal to merge the 2 fonts into a single font. That's not how the tech works, the fact that the same font files are deployed in X Y or Z packages does not change the legal or technical content of those files. What you see as single font entries in font lists are a collection of font files assembled by fontconfig. > The only legal way to merge the fonts would be to stick to Liberation > 1 for > Liberation Sans too, Nope, because different faces of the same font family are deployed with different font files, so regardless of the packaging, Liberation Sans Narrow Bold will always exist in a different file that Liberation Sans Bold (unless you try to go ttc or otc, that no one except CJK font users ever tried to do, because of the huge legal and management hell of mixing different faces and font families in a simgle file). The legalities hit when you attempt to copy glyph or hinting material from Liberation Sans Bold v1 to Liberation Sans Bold v2, because Liberation Sans Bold is a single font face, that exists in a single font file. > This is absolutely wrong. The reason we have this breakage right now > is > because somebody d
DNF system-upgrade instructions on docs.fp.o
Hello, Sometime ago, the dnf system-upgrade instructions were moved from the wiki[0] to docs.fp.o[1]. Could folks please take a few minutes to check it for correctness? If it's fine, we should make the wiki page redirect to the quick-doc too. [0] https://fedoraproject.org/wiki/DNF_system_upgrade [1] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
Upcoming change for adopting orphaned packages and anitya integration
Good Morning Everyone, The Fedora Infrastructure team has been working on making changes to the way orphaned packages are being adopted as well as the way to set the monitoring status for the integration with anitya (ie: https://release-monitoring.org). ## Orphan packages Currently if a package is orphaned there is no way to adopt it easily on dist-git (https://src.fedoraproject.org). You need to open a ticket on the releng issue tracker and wait for someone to process that ticket. This is going to change, new versions of pagure-dist-git and pagure will offer a button on the left hand side menu offering to adopt orphaned packages. This is already live in staging, so you can see how it looks there, for example: https://src.stg.fedoraproject.org/rpms/aasaver (you'll need to be logged in) Note: if the package is retired, you will still have to go through a releng ticket as it will need to be unblocked in koji. ## Anitya integration Currently if you want to tweak the setting for the anitya integration, you need to open a pull-request on the fedora-scm-requests project at https://pagure.io/releng/fedora-scm-requests/ That git repo is pretty big and once your pull-request is finally open, you still have to wait for someone to merge it. This is also going to change, new versions of pagure and pagure-dist-git offer a drop-down menu on the left hand side menu to see and adjust the monitoring status of the project. This is also live in staging and you can see an example of a project who has set its monitoring status to "monitoring": https://src.stg.fedoraproject.org/rpms/0ad (The status in staging have been imported from the fedora-scm-requests repo) ## Feedback Feel free to play with this in staging and let us know if there is anything that isn't working as expected or that you would like to change before we push this to production (post F31-beta freeze). Once the new versions of pagure, pagure-dist-git, anitya and the-new-hotness have been deployed to production we will send another announcement for the change and work on getting the different documentations updated. Looking forward to hear from you, Michal and Pierre - On behalf of the Fedora Infrastructure team ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: DNF system-upgrade instructions on docs.fp.o
On Fri, Sep 13, 2019 at 01:11:28PM +0100, Ankur Sinha wrote: > Hello, > > Sometime ago, the dnf system-upgrade instructions were moved from the > wiki[0] to docs.fp.o[1]. > > Could folks please take a few minutes to check it for correctness? If > it's fine, we should make the wiki page redirect to the quick-doc too. > > [0] https://fedoraproject.org/wiki/DNF_system_upgrade > [1] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ Oh, https://github.com/rpm-software-management/dnf-plugin-system-upgrade is not a separate project anymore. It's part of the dnf plugins now, so the link needs to be updated. 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
Re: Upcoming change for adopting orphaned packages and anitya integration
On Fri, Sep 13, 2019 at 12:32:34PM +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > The Fedora Infrastructure team has been working on making changes to the way > orphaned packages are being adopted as well as the way to set the monitoring > status for the integration with anitya (ie: https://release-monitoring.org). That is great news! > ## Orphan packages > > Currently if a package is orphaned there is no way to adopt it easily on > dist-git (https://src.fedoraproject.org). You need to open a ticket on the > releng issue tracker and wait for someone to process that ticket. > > This is going to change, new versions of pagure-dist-git and pagure will > offer a > button on the left hand side menu offering to adopt orphaned packages. > > This is already live in staging, so you can see how it looks there, for > example: > https://src.stg.fedoraproject.org/rpms/aasaver (you'll need to be logged in) > > Note: if the package is retired, you will still have to go through a releng > ticket as it will need to be unblocked in koji. I tried with a few packages, and I always get the dialog about the package being retired. I couldn't find a package which was orphaned but not retired. Since pagure seems to know that the package was retired, an RFE: please make it prominently visible that the package has been retired. Something like red background for the whole page would IMHO be very appropriate. Right now one needs to click on some buttons to be told that the package is retired. 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
Re: mock -r fedora-31-i386 broken
On 9/13/19 1:34 PM, Vít Ondruch wrote: Just FTR, this was brought up already: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2V2RRTT7DTHWANFHL6YBVM7RILCWDGGT/ Understood - Give me a ping when Fedora has a usable infrastructure again. I'll suspend all Fedora activities until then. Right now, this stuff is just in unusable shape. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Intention to retire Release Notes RPM
On Thu, Sep 12, 2019 at 8:01 PM Miroslav Suchý wrote: > Dne 02. 09. 19 v 13:57 Brian (bex) Exelbierd napsal(a): > > Closing the loop: This package has been retired via `fedpkg retire` in > f31 and rawhide. > > Can you add it to fedora-obsolete-packages? Otherwise the old version will > remain on every Fedora machine. > I am not 100% sure how to do this, but it appears that I file a BZ and a proven package or the fedora-obsoletes-packages maintainer does the deed. https://bugzilla.redhat.com/show_bug.cgi?id=1752016 If you have additional guidance or if I should take additional action, please let me know. regards, bex > > -- > Miroslav Suchy, RHCA > Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.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
Fedora 31 compose report: 20190913.n.0 changes
OLD: Fedora-31-20190912.n.0 NEW: Fedora-31-20190913.n.0 = SUMMARY = Added images:0 Dropped images: 8 Added packages: 0 Dropped packages:0 Upgraded packages: 1 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 60.86 KiB Size of downgraded packages: 0 B Size change of upgraded packages: 318 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-31-20190912.n.0.iso Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-31-20190912.n.0.iso Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-31-20190912.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-31-20190912.n.0.s390x.tar.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190912.n.0.s390x.qcow2 Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190912.n.0.s390x.vmdk Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190912.n.0.s390x.raw.xz Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-31-20190912.n.0.s390x.tar.xz = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: kde-settings-31.0-1.fc31 Old package: kde-settings-30.3-1.fc31 Summary: Config files for kde RPMs: kde-settings kde-settings-plasma kde-settings-pulseaudio qt-settings Size: 60.86 KiB Size change: 318 B Changelog: * Tue Sep 10 2019 Adam Williamson - 31.0-1 - Bump for Fedora 31 (#1749086) = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-31-20190913.n.0 compose check report
No missing expected images. Failed openQA tests: 4/152 (x86_64), 1/2 (arm) Old failures (same test failed in Fedora-31-20190912.n.0): ID: 450214 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/450214 ID: 450249 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/450249 ID: 450250 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/450250 ID: 450252 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/450252 ID: 450255 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/450255 Soft failed openQA tests: 2/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-31-20190912.n.0): ID: 450230 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/450230 ID: 450327 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/450327 Passed openQA tests: 146/152 (x86_64) New passes (same test not passed in Fedora-31-20190912.n.0): ID: 450246 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/450246 Skipped non-gating openQA tests: 1 of 154 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.05 to 0.25 Previous test data: https://openqa.fedoraproject.org/tests/449227#downloads Current test data: https://openqa.fedoraproject.org/tests/450185#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used mem changed from 882 MiB to 719 MiB Previous test data: https://openqa.fedoraproject.org/tests/449264#downloads Current test data: https://openqa.fedoraproject.org/tests/450222#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used mem changed from 741 MiB to 841 MiB System load changed from 0.28 to 0.70 Previous test data: https://openqa.fedoraproject.org/tests/449266#downloads Current test data: https://openqa.fedoraproject.org/tests/450224#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 735 MiB to 902 MiB 1 packages(s) added since previous compose: f31-backgrounds-kde 2 packages(s) removed since previous compose: f30-backgrounds-base, f30-backgrounds-kde 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.5-org.freedesktop.problems@0.service loaded active running dbus-:1.5-org.freedesktop.problems@0.service System load changed from 2.07 to 0.74 Average CPU usage changed from 74.60952381 to 15.40476190 Previous test data: https://openqa.fedoraproject.org/tests/449279#downloads Current test data: https://openqa.fedoraproject.org/tests/450237#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 1 packages(s) added since previous compose: f31-backgrounds-kde 2 packages(s) removed since previous compose: f30-backgrounds-base, f30-backgrounds-kde 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service System load changed from 0.64 to 0.20 Previous test data: https://openqa.fedoraproject.org/tests/449281#downloads Current test data: https://openqa.fedoraproject.org/tests/450239#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 7 MiB to 3 MiB System load changed from 0.55 to 0.39 Previous test data: https://openqa.fedoraproject.org/tests/449296#downloads Current test data: https://openqa.fedoraproject.org/tests/450254#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: System load changed from 0.42 to 0.26 Average CPU usage changed from 7.03809524 to 17.32380952 Previous test data: https://openqa.fedoraproject.org/tests/449298#downloads Current test data: https://openqa.fedoraproject.org/tests/450256#downloads Installed system changes in test x86_64 universal install_package_set_minimal: System load changed from 0.02 to 0.13 Previous test data: https://openqa.fedoraproject.org/tests/449313#downloads Current test data: https://openqa.fedorap
How do we fix: "BuildError: package mingw-portablexdr is blocked for tag f31-updates-candidate"?
Normally we would request a branch. Both maintainers tried that but the request was closed without substantive comment: https://pagure.io/releng/fedora-scm-requests/issue/16653 https://pagure.io/releng/fedora-scm-requests/issue/16677 However still cannot do builds in f31: https://koji.fedoraproject.org/koji/taskinfo?taskID=37646364 "BuildError: package mingw-portablexdr is blocked for tag f31-updates-candidate" How do we fix this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20190913.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 5 of 45 required tests failed, 2 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 21/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190912.n.2): ID: 450390 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/450390 ID: 450400 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/450400 ID: 450408 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/450408 Old failures (same test failed in Fedora-Rawhide-20190912.n.2): ID: 450357 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/450357 ID: 450358 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/450358 ID: 450359 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/450359 ID: 450360 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/450360 ID: 450362 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/450362 ID: 450363 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/450363 ID: 450368 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/450368 ID: 450372 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/450372 ID: 450380 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/450380 ID: 450386 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/450386 ID: 450388 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/450388 ID: 450396 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/450396 ID: 450404 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/450404 ID: 450405 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/450405 ID: 450406 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/450406 ID: 450473 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/450473 ID: 450474 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/450474 ID: 450480 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/450480 ID: 450481 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/450481 Soft failed openQA tests: 7/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20190912.n.2): ID: 450376 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/450376 ID: 450378 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/450378 ID: 450384 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/450384 ID: 450410 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/450410 ID: 450475 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/450475 ID: 450477 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/450477 ID: 450482 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/450482 Passed openQA tests: 116/152 (x86_64) Skipped non-gating openQA tests: 9 of 154 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 services(s) added since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.5-org.freedesktop.problems@0.service loaded active running dbus-:1.5-org.freedesktop.problems@0.service System load changed from 0.36 to 0.51 Previous test data: http
Re: Better interactivity in low-memory situations
> On Mo, 12.08.19 09:40, Chris Murphy (lists(a)colorremedies.com) wrote: > > > Ideally, GNOME would run all its apps as systemd --user services. We > could then set DefaultMemoryHigh= globally for the systemd --user > instance to some percentage value (which is taken relative to the > physical RAM size). This would then mean every user app individually > could use — let's say — 75% of the physical RAM size and when it wants > more it would be penalized during reclaim compared to apps using less. > > If GNOME would run all apps as user services we could do various other > nice things too. For example, it could dynamically assign the fg app > more CPU/IO weight than the bg apps, if the system is starved of > both. > Running each app as systemd --user services is something we've been trying to encourage teams to do at FB. It lets monitor things much better using the cgroup control files. In addition, it lets us configure oomd ( https://github.com/facebookincubator/oomd ) to do much more intelligent things than kill the entire session. oomd is being proposed as a fedora package right now. I think the last missing piece for oomd to be really useful on desktop systems is the --user slice changes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Better interactivity in low-memory situations
Our team at FB is working on a similar (but more generic) solution. All of our work is open source / upstreamed into the linux kernel and we're running it in production on quite a large scale already. Results are very promising. We'll be presenting about it at All Systems Go (multiple talks) this year. We'd love to chat in-person if anyone is interested. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Upcoming change for adopting orphaned packages and anitya integration
On Fri, Sep 13, 2019 at 12:51:20PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Sep 13, 2019 at 12:32:34PM +0200, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > The Fedora Infrastructure team has been working on making changes to the way > > orphaned packages are being adopted as well as the way to set the monitoring > > status for the integration with anitya (ie: https://release-monitoring.org). > > That is great news! > > > ## Orphan packages > > > > Currently if a package is orphaned there is no way to adopt it easily on > > dist-git (https://src.fedoraproject.org). You need to open a ticket on the > > releng issue tracker and wait for someone to process that ticket. > > > > This is going to change, new versions of pagure-dist-git and pagure will > > offer a > > button on the left hand side menu offering to adopt orphaned packages. > > > > This is already live in staging, so you can see how it looks there, for > > example: > > https://src.stg.fedoraproject.org/rpms/aasaver (you'll need to be logged in) > > > > Note: if the package is retired, you will still have to go through a releng > > ticket as it will need to be unblocked in koji. > > I tried with a few packages, and I always get the dialog about the package > being retired. I couldn't find a package which was orphaned but not retired. > > Since pagure seems to know that the package was retired, an RFE: > please make it prominently visible that the package has been > retired. Something like red background for the whole page would IMHO > be very appropriate. Right now one needs to click on some buttons to > be told that the package is retired. That's a good suggestion, it'll require a bit more work but I see a way to do this. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Possibly unresponsive maintainer: vakwetu
On Fri, Sep 13, 2019 at 3:57 PM Ade Lee wrote: > > Hi all, > > I transferred ownership a little while back to the resteasy package to > the SIG via Dinesh, copied above. Hi Ade, This is not accurate. You are still listed as the main admin for resteasy: https://src.fedoraproject.org/rpms/resteasy If you want to officially transfer ownership to someone else, you can do this at ^ under the settings tab → Give Project. Also, which SIG are you referring to? At least the Stewardship SIG doesn't track this package yet. Fabio > Ade > > On Fri, 2019-09-13 at 12:53 +0200, Miro Hrončok wrote: > > On 13. 09. 19 12:05, Fabio Valentini wrote: > > > On Tue, Jul 9, 2019 at 8:17 PM Fabio Valentini > > > wrote: > > > > On Tue, Jul 9, 2019 at 7:51 PM Dinesh Prasanth Moluguwan > > > > Krishnamoorthy wrote: > > > > > Hello everyone, > > > > > > > > > > As Rob had responded earlier, he is away for few weeks. A while > > > > > back, I > > > > > spoke to him in person about handing over the RESTeasy packages > > > > > to the > > > > > Fedora SIG. He had agreed to it. Once he is back, I will remind > > > > > him to > > > > > transfer those packages to the SIG. > > > > > > > > > > PS: Dogtag PKI depends on those RESTeasy packages. > > > > I know, which is why I am interested in fixing it (it's currently > > > > broken in rawhide). > > > Just a quick update: After two more months, the package has still > > > not > > > been touched (since 2016), and it is still broken on fedora 31+. > > > > I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1751976 > > > > Does anyone knows how to contact the maintainer? > > > > Links to all other bug reports open on resteasy: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1736585 (FTBFS) > > https://bugzilla.redhat.com/show_bug.cgi?id=1372118 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1372122 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1372125 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1372130 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1404912 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1456313 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1471273 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1471275 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1471277 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1471279 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1480769 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1481780 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1539175 (CVE) > > https://bugzilla.redhat.com/show_bug.cgi?id=1590941 (CVE) > > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Proven packager help request: DCMTK (and dependent packages) require update in F29/F30
Hello, A CVE[1] in dcmtk was fixed in 3.6.4 which is in F31+. F29 and F30 are still at 3.6.2 however, and need updating. This includes a soname bump ([2] vs [3]), though, so dependent packages will also need to be rebuilt and pushed as updates all at once. sudo dnf repoquery --source --whatrequires 'libdcm*(64bit)' [sudo] password for asinha: Last metadata expiration check: 0:53:07 ago on Fri 13 Sep 2019 14:07:55 BST. OpenImageIO-2.0.7-1.fc30.src.rpm OpenImageIO-2.0.9-1.fc30.src.rpm aeskulap-0.2.2-0.37.beta2.fc30.src.rpm ctk-0.1-0.10.20171224git71799c2.fc29.src.rpm dcmtk-3.6.2-4.fc29.src.rpm gtatool-2.2.0-11.fc28.src.rpm gtatool-2.2.3-1.fc30.src.rpm orthanc-1.5.4-1.fc30.src.rpm They all build correctly in F31 with the new version, so I do not expect any build failures. Could I please solicit the help of a proven-packager to rebuild them all in F29/F30 and push combined updates please? If you maintain any of these packages and have any concerns, please let us know. [1] https://bugzilla.redhat.com/show_bug.cgi?id=173 [2] https://koji.fedoraproject.org/koji/rpminfo?rpmID=14644638 [3] https://koji.fedoraproject.org/koji/rpminfo?rpmID=18968192 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
Fedora rawhide compose report: 20190913.n.1 changes
OLD: Fedora-Rawhide-20190912.n.2
NEW: Fedora-Rawhide-20190913.n.1
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 4
Dropped packages:1
Upgraded packages: 33
Downgraded packages: 0
Size of added packages: 1.72 MiB
Size of dropped packages:297.80 KiB
Size of upgraded packages: 1.60 GiB
Size of downgraded packages: 0 B
Size change of upgraded packages: -548.69 KiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20190913.n.1.iso
= DROPPED IMAGES =
= ADDED PACKAGES =
Package: oomd-0.2.0-4.fc32
Summary: Userspace Out-Of-Memory (OOM) killer
RPMs:oomd
Size:870.41 KiB
Package: python-aexpect-1.5.1-5.module_f32+6414+a923f257
Summary: A python library to control interactive applications
RPMs:python3-aexpect
Size:51.09 KiB
Package: python-avocado-69.1-3.module_f32+6414+a923f257
Summary: Framework with tools and libraries for Automated Testing
RPMs:python-avocado-bash python-avocado-common python-avocado-examples
python3-avocado python3-avocado-plugins-glib python3-avocado-plugins-golang
python3-avocado-plugins-loader-yaml python3-avocado-plugins-output-html
python3-avocado-plugins-result-upload python3-avocado-plugins-resultsdb
python3-avocado-plugins-varianter-cit python3-avocado-plugins-varianter-pict
python3-avocado-plugins-varianter-yaml-to-mux
Size:746.03 KiB
Package: python-fsspec-0.4.4-1.fc32~bootstrap
Summary: Specification for Pythonic file system interfaces
RPMs:python3-fsspec
Size:92.13 KiB
= DROPPED PACKAGES =
Package: decibel-audio-player-1.08-21.fc32
Summary: Music player for GNOME
RPMs:decibel-audio-player
Size:297.80 KiB
= UPGRADED PACKAGES =
Package: buildah-1.12.0-0.12.dev.git9cac447.fc32
Old package: buildah-1.12.0-0.11.dev.git20a33e0.fc32
Summary: A command line tool used for creating OCI Images
RPMs: buildah
Size: 36.93 MiB
Size change: 33.52 KiB
Changelog:
* Thu Sep 12 2019 Lokesh Mandvekar (Bot) -
1.12.0-0.12.dev.git9cac447
- autobuilt 9cac447
Package: ddgr-1.7-1.fc32
Old package: ddgr-1.6-2.fc30
Summary: DuckDuckGo from the terminal
RPMs: ddgr
Size: 48.30 KiB
Size change: 464 B
Changelog:
* Wed Jul 24 2019 Fedora Release Engineering -
1.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Thu Sep 12 2019 Robert-Andr?? Mauchin - 1.7-1
- Release 1.7
Package: dino-0.0-0.13.20190912.git.a96c801.fc32
Old package: dino-0.0-0.12.20190830.git.016ab2c.fc32
Summary: Modern XMPP ("Jabber") Chat Client using GTK+/Vala
RPMs: dino dino-devel
Size: 5.98 MiB
Size change: 42.46 KiB
Changelog:
* Thu Sep 12 2019 Randy Barlow -
0.0-0.13.20190912.git.a96c8014
- Update to a96c8014.
- Fixes CVE-2019-16235 (#1751847), CVE-2019-16236 (#1751849), and
CVE-2019-16237 (#1751851).
- https://github.com/dino/dino/compare/016ab2c1...a96c8014
Package: ensmallen-2.10.2-1.fc32
Old package: ensmallen-1.16.2-1.fc32
Summary: Header-only C++ library for efficient mathematical optimization
RPMs: ensmallen-devel
Size: 948.24 KiB
Size change: 84.45 KiB
Changelog:
* Wed Sep 11 2019 Ryan Curtin - 2.10.2-1
- Update to latest stable version.
Package: f31-backgrounds-31.0.2-4.fc32
Old package: f31-backgrounds-31.0.2-3.fc32
Summary: Fedora 31 default desktop background
RPMs: f31-backgrounds f31-backgrounds-animated f31-backgrounds-base
f31-backgrounds-extras-base f31-backgrounds-extras-gnome
f31-backgrounds-extras-kde f31-backgrounds-extras-mate
f31-backgrounds-extras-xfce f31-backgrounds-gnome f31-backgrounds-kde
f31-backgrounds-mate f31-backgrounds-xfce
Size: 329.87 MiB
Size change: 2.50 KiB
Changelog:
* Thu Sep 12 2019 Adam Williamson - 31.0.2-4
- Drop the unnecessary downstream copy of metadata.desktop
- Install upstream copy to the place we were installing downstream copy
Package: fedora-gather-easyfix-0.2.1-24.fc32
Old package: fedora-gather-easyfix-0.2.1-23.fc32
Summary: Gather easyfix tickets across fedorahosted projects
RPMs: fedora-gather-easyfix
Size: 125.50 KiB
Size change: 13 B
Changelog:
* Thu Sep 12 2019 Pierre-Yves Chibon - 0.2.1-24
- rebuilt
Package: fedora-obsolete-packages-32-15
Old package: fedora-obsolete-packages-32-14
Summary: A package to obsolete retired packages
RPMs: fedora-obsolete-packages
Size: 44.49 KiB
Size change: 1.25 KiB
Changelog:
* Thu Sep 12 2019 Zbigniew J??drzejewski-Szmek - 32-15
- Obsolete a bunch of python2 packages based on testing the upgrade
path from F30 to F31.
Package: gnome-backgrounds-3.34.0-1.fc32
Old package: gnome-backgrounds-3.32.0-2.fc31
Summary: Desktop backgrounds packaged with the GNOME desktop
RPMs: gnome-backgro
Re: Proven packager help request: DCMTK (and dependent packages) require update in F29/F30
Ankur Sinha wrote on 2019/09/13 23:07: Hello, A CVE[1] in dcmtk was fixed in 3.6.4 which is in F31+. F29 and F30 are still at 3.6.2 however, and need updating. This includes a soname bump ([2] vs [3]), though, so dependent packages will also need to be rebuilt and pushed as updates all at once. sudo dnf repoquery --source --whatrequires 'libdcm*(64bit)' [sudo] password for asinha: Last metadata expiration check: 0:53:07 ago on Fri 13 Sep 2019 14:07:55 BST. OpenImageIO-2.0.7-1.fc30.src.rpm OpenImageIO-2.0.9-1.fc30.src.rpm aeskulap-0.2.2-0.37.beta2.fc30.src.rpm ctk-0.1-0.10.20171224git71799c2.fc29.src.rpm dcmtk-3.6.2-4.fc29.src.rpm gtatool-2.2.0-11.fc28.src.rpm gtatool-2.2.3-1.fc30.src.rpm orthanc-1.5.4-1.fc30.src.rpm They all build correctly in F31 with the new version, so I do not expect any build failures. Could I please solicit the help of a proven-packager to rebuild them all in F29/F30 and push combined updates please? If you maintain any of these packages and have any concerns, please let us know. [1] https://bugzilla.redhat.com/show_bug.cgi?id=173 [2] https://koji.fedoraproject.org/koji/rpminfo?rpmID=14644638 [3] https://koji.fedoraproject.org/koji/rpminfo?rpmID=18968192 Well, actually some google search result is that the actual fix seems https://github.com/commontk/DCMTK/commit/40917614e and the tracker is https://support.dcmtk.org/redmine/issues/858 ref: https://nvd.nist.gov/vuln/detail/CVE-2019-1010228 So it seems if the above patch only can be applied, no rebuild is needed. Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mock -r fedora-31-i386 broken
On 13.09.2019 14:53, Ralf Corsepius wrote: > Understood - Give me a ping when Fedora has a usable infrastructure again. What is the purpose of using i386 mock today? -- 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
Help needed with failing PPC build: cannot find MPI with openmpi
Hello, A tool I am trying to package is failing only on PPC somehow: https://bugzilla.redhat.com/show_bug.cgi?id=1731487 > make[2]: Leaving directory > '/builddir/build/BUILD/MUSIC-a78a8e2c90b07274db94265db75c320dbb01f9fb/MUSIC-a78a8e2c90b07274db94265db75c320dbb01f9fb-openmpi/src' > BUILDSTDERR: error.cc: In function 'void MUSIC::error()': > BUILDSTDERR: error.cc:36:5: error: 'MPI' has not been declared > BUILDSTDERR:36 | MPI::COMM_WORLD.Abort (1); > BUILDSTDERR: | ^~~ > BUILDSTDERR: error.cc: In function 'int MUSIC::getRank()': > BUILDSTDERR: error.cc:70:9: error: 'MPI' has not been declared > BUILDSTDERR:70 | if (MPI::Is_initialized ()) > BUILDSTDERR: | ^~~ > BUILDSTDERR: error.cc:71:14: error: 'MPI' has not been declared > BUILDSTDERR:71 | return MPI::COMM_WORLD.Get_rank (); > BUILDSTDERR: | ^~~ > BUILDSTDERR: make[2]: *** [Makefile:739: libmusic_la-error.lo] Error 1 On all other arches, it builds just fine, so there's something different with the openmpi package on ppc here. Any ideas? -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: Possibly unresponsive maintainer: vakwetu
Hello everyone, Ade recently added me as an admin to the project. I had added resteasy to the Stewardship SIG a while ago by following the (legacy) instructions on the SIG webpage. The package was then removed since it was little too much for the SIG. A lot of deps were brought in by resteasy that needed SIG's touch. Currently, the members of the dogtag team own this package. Regards, --Dinesh On Fri, 2019-09-13 at 16:03 +0200, Fabio Valentini wrote: > On Fri, Sep 13, 2019 at 3:57 PM Ade Lee wrote: > > Hi all, > > > > I transferred ownership a little while back to the resteasy package > > to > > the SIG via Dinesh, copied above. > > Hi Ade, > > This is not accurate. You are still listed as the main admin for > resteasy: > https://src.fedoraproject.org/rpms/resteasy > > If you want to officially transfer ownership to someone else, you can > do this at ^ under the settings tab → Give Project. > > Also, which SIG are you referring to? At least the Stewardship SIG > doesn't track this package yet. > > Fabio > > > Ade > > > > On Fri, 2019-09-13 at 12:53 +0200, Miro Hrončok wrote: > > > On 13. 09. 19 12:05, Fabio Valentini wrote: > > > > On Tue, Jul 9, 2019 at 8:17 PM Fabio Valentini< > > > > decatho...@gmail.com > > > > > wrote: > > > > > On Tue, Jul 9, 2019 at 7:51 PM Dinesh Prasanth Moluguwan > > > > > Krishnamoorthy wrote: > > > > > > Hello everyone, > > > > > > > > > > > > As Rob had responded earlier, he is away for few weeks. A > > > > > > while > > > > > > back, I > > > > > > spoke to him in person about handing over the RESTeasy > > > > > > packages > > > > > > to the > > > > > > Fedora SIG. He had agreed to it. Once he is back, I will > > > > > > remind > > > > > > him to > > > > > > transfer those packages to the SIG. > > > > > > > > > > > > PS: Dogtag PKI depends on those RESTeasy packages. > > > > > I know, which is why I am interested in fixing it (it's > > > > > currently > > > > > broken in rawhide). > > > > Just a quick update: After two more months, the package has > > > > still > > > > not > > > > been touched (since 2016), and it is still broken on fedora > > > > 31+. > > > > > > I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1751976 > > > > > > Does anyone knows how to contact the maintainer? > > > > > > Links to all other bug reports open on resteasy: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1736585 (FTBFS) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1372118 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1372122 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1372125 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1372130 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1404912 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1456313 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1471273 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1471275 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1471277 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1471279 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1480769 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1481780 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1539175 (CVE) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1590941 (CVE) > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: DNF system-upgrade instructions on docs.fp.o
On Fri, Sep 13, 2019 12:26:34 +, Zbigniew Jędrzejewski-Szmek wrote: > > Oh, https://github.com/rpm-software-management/dnf-plugin-system-upgrade > is not a separate project anymore. It's part of the dnf plugins now, > so the link needs to be updated. Opened a PR for this: https://pagure.io/fedora-docs/quick-docs/pull-request/144 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: mock -r fedora-31-i386 broken
On Fri, 2019-09-13 at 16:22 +0200, Vitaly Zaitsev via devel wrote: > On 13.09.2019 14:53, Ralf Corsepius wrote: > > Understood - Give me a ping when Fedora has a usable infrastructure > > again. > > What is the purpose of using i386 mock today? how you build a multilib in mock or in copr ? > -- > 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 -- 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
Re: mock -r fedora-31-i386 broken
On Fri, Sep 13, 2019 at 8:35 AM Vitaly Zaitsev via devel wrote: > What is the purpose of using i386 mock today? To diagnose 32-bit-specific problems in packages. I've had to do that lots of times. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upcoming change for adopting orphaned packages and anitya integration
Il 13/09/19 12:32, Pierre-Yves Chibon ha scritto: > ## Orphan packages > > Currently if a package is orphaned there is no way to adopt it easily on > dist-git (https://src.fedoraproject.org). You need to open a ticket on the > releng issue tracker and wait for someone to process that ticket. > > This is going to change, new versions of pagure-dist-git and pagure will > offer a > button on the left hand side menu offering to adopt orphaned packages. > > This is already live in staging, so you can see how it looks there, for > example: > https://src.stg.fedoraproject.org/rpms/aasaver (you'll need to be logged in) > > Note: if the package is retired, you will still have to go through a releng > ticket as it will need to be unblocked in koji. In my opinion, that button should better be showed on top of the page, side by side with "fork", "clone", etc. and it should be more emphasized. > ## Anitya integration > > Currently if you want to tweak the setting for the anitya integration, you > need > to open a pull-request on the fedora-scm-requests project at > https://pagure.io/releng/fedora-scm-requests/ > That git repo is pretty big and once your pull-request is finally open, you > still have to wait for someone to merge it. > > This is also going to change, new versions of pagure and pagure-dist-git > offer a > drop-down menu on the left hand side menu to see and adjust the monitoring > status of the project. > > This is also live in staging and you can see an example of a project who has > set > its monitoring status to "monitoring": > https://src.stg.fedoraproject.org/rpms/0ad > > (The status in staging have been imported from the fedora-scm-requests repo) Can we have some feedback when we change the monitoring status? I mean, something like a popup which says "successfully changed status", or a green icon popping up... what feedback is there actually if something goes wrong after a user selects the status from the list? Nice work! Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Need help: SWIG related build error for python-pivy?
On Thu, Sep 12, 2019 at 10:51 AM Richard Shaw wrote: > On Thu, Sep 5, 2019 at 9:18 PM Jerry James wrote: >> The errors indicate that the compiler cannot find the standard C++ >> headers. These are the first things I would check: >> 1. Does the spec file include BuildRequires: gcc-c++? > > I didn't (hadn't needed it before) but I added it with no change to the > errors... > >> 2. Is setup.py choosing g++ as the compiler? > > I can't tell, it's just running swig with the -c++ option which is correct. I > don't know what swig is doing in the background... > >> 3. Is -nostdinc++ showing up in the build flags? > > Not that I can tell... Okay, and then I also said: >> If all of those check out, maybe you could share your spec files. I'm happy to help you look at this, but you'll need to provide a way to reproduce the issue. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mock -r fedora-31-i386 broken
On 13.09.2019 17:10, Sérgio Basto wrote: > how you build a multilib in mock or in copr ? Koji --scratch. -- 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
Re: mock -r fedora-31-i386 broken
On 13.09.2019 17:27, Jerry James wrote: > To diagnose 32-bit-specific problems in packages. You don't need to do it anymore on Fedora 31+ due to i686 deprecation (except of multilib shared libraries, needed by Steam and Wine). -- 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
Re: Need help: SWIG related build error for python-pivy?
On Fri, Sep 13, 2019 at 10:36 AM Jerry James wrote: > On Thu, Sep 12, 2019 at 10:51 AM Richard Shaw > wrote: > > On Thu, Sep 5, 2019 at 9:18 PM Jerry James wrote: > >> The errors indicate that the compiler cannot find the standard C++ > >> headers. These are the first things I would check: > >> 1. Does the spec file include BuildRequires: gcc-c++? > > > > I didn't (hadn't needed it before) but I added it with no change to the > errors... > > > >> 2. Is setup.py choosing g++ as the compiler? > > > > I can't tell, it's just running swig with the -c++ option which is > correct. I don't know what swig is doing in the background... > > > >> 3. Is -nostdinc++ showing up in the build flags? > > > > Not that I can tell... > > Okay, and then I also said: > > >> If all of those check out, maybe you could share your spec files. > > I'm happy to help you look at this, but you'll need to provide a way > to reproduce the issue. > I actually did make some progress... Pivy currently passes -includeall to swig, and from my googling that's generally a bad idea so I'm applying a patch to remove it. I still don't know much about swig but my understanding is that keeps it from trying to process all the headers and instead just the ones in the swig template. Now the error is narrowed down to: But it's erroring on the second 2nd binding (and there's many more) === Generating pivy/coin_wrap.cpp for coin === swig -w302,306,307,312,314,325,361,362,467,389,503,509,510 -py3 -c++ -python -D__PIVY__ -I. -Ifake_headers -I"/usr/include" -Iinterfaces -o pivy/coin_wrap.cpp interfaces/coin.i === Generating pivy/gui/soqt_wrap.cpp for soqt === swig -w302,306,307,312,314,325,361,362,467,389,503,509,510 -py3 -c++ -python -D__PIVY__ -I. -Ifake_headers -I"/usr/include" -Iinterfaces -o pivy/gui/soqt_wrap.cpp interfaces/soqt.i SWIG did not generate wrappers successfully! ** Aborting ** BUILDSTDERR: Inventor/fields/SoField.i:10: Warning 303: %extend defined for an undeclared class SoField. BUILDSTDERR: Inventor/SbString.i:17: Warning 303: %extend defined for an undeclared class SbString. BUILDSTDERR: /usr/include/Inventor/Qt/devices/SoQtDevice.h:73: Error: Syntax error in input(1). Next I'm going to patch it to run swig with debugging so I can get more details... My guess is there was an incompatible change between Coin3 and Coin4 but I'm running the latest checkout of Pivy and it's all the same upstream. If that's the case then they messed up. 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: mock -r fedora-31-i386 broken
On Fri, Sep 13, 2019 at 9:49 AM Vitaly Zaitsev wrote: > You don't need to do it anymore on Fedora 31+ due to i686 deprecation > (except of multilib shared libraries, needed by Steam and Wine). So, yes, i still do need to do it for multilib shared libraries, and also for the 32-bit ARM architecture. Debugging on 32-bit x86 is MUCH more convenient than debugging on 32-bit ARM, because I don't have to emulate a CPU to do so. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (~400 during this week)
On Mon, 9 Sep 2019 23:49:17 +0200, Miro Hrončok wrote: > Request package ownership via releng issues: > https://pagure.io/releng/issues How? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Orphaned packages to be retired (~400 during this week)
On Fri, Sep 13, 2019 at 6:11 PM Michael Schwendt wrote: > > On Mon, 9 Sep 2019 23:49:17 +0200, Miro Hrončok wrote: > > > Request package ownership via releng issues: > > https://pagure.io/releng/issues > > How? Click "New Issue", fill out "package_unorphan" or "package_unretirement" template, submit ticket. Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Possibly unresponsive maintainer: vakwetu
On 13. 09. 19 16:33, Dinesh Prasanth Moluguwan Krishnamoorthy wrote: Currently, the members of the dogtag team own this package. Not correct, it is still owned by vakwetu. -- 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: Donate 1 minute of your time to test upgrades from F30 to F31
On Fri, 2019-09-13 at 06:23 +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Sep 12, 2019 at 02:47:20PM -0600, Nathanael D. Noblet wrote: > > Is this an error with gegl03? > > https://bugzilla.redhat.com/show_bug.cgi?id=1703828 > The update there seems to have fixed the issue and I now get to the y/n prompt successfully. Sincerely, -- Nathanael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: MPFR 4
On Wed, Jul 24, 2019 at 12:00 PM Pavel Cahyna wrote: > On Thu, Jul 18, 2019 at 11:31:02AM -0600, Jerry James wrote: > > I would like to ask again if anyone who works at RedHat can check on > > Pavel's status. It would be good to know if he is not available until > > , or if he is too busy to pay attention to mpfr. Thank you. > > Hi, sorry for the delayed reply. I will not be able to look into it > before Monday. [Nearly 2 months later] I need some advice on how to proceed. I am ready to move the mpfr 4 change forward, but the 2 lines above are the only communication I've ever had from the package owner. There is already a change page here, which could be reused with some minor edits: https://fedoraproject.org/wiki/Changes/mpfr-4.0.0 And that change page links to an existing releng issue where releng agreed that the only action required by them is management of a side tag: https://pagure.io/releng/issue/7247 I would like to revive/hijack those to get this moving again. What should I do about the maintainer, who is probably very busy with other work? Since gcc uses mpfr, the package is a critical one for Fedora. If it is not inconsistent with RedHat's goals or policies, could I perhaps step into a comaintainer role for mpfr? Since this thread is so old, I will repeat that I have done successful x86_64 mock builds of all dependent packages. I've got the right sequence of builds all worked out and ready to go. There may be problems on other arches; if so, I am ready to fix them. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F30 to F31
On Wed, Sep 11, 2019 at 7:14 PM Jerry James wrote: > No errors for me, but 3 downgrades: > > Downgrading: > gap-pkg-edim x86_64 1.3.3-6.fc31fedora78 > k > gap-pkg-genssnoarch 1.6.5-6.fc31fedora56 > k > python3-parsonoarch 0.5.1-1.fc31fedora 142 > k > > The first two are mine. I did those builds right about the time that > bodhi was enabled for F31. After it was enabled, I tried to create > updates for them just in case they hadn't quite made it in, and bodhi > told me there were no candidate builds. I just tried again, and bodhi > *still* tells me there are no candidate builds. These are the latest > actual builds for them: > > gap-pkg-edim-1.3.5-1.fc31 > gap-pkg-genss-1.6.6-1.fc31 Bodhi shows that updates for both of these packages exist already. Both are labeled "Automatic update for ". The logs for both include "This update has been submitted for stable by bodhi", but they never actually reached stable. I clicked on the "Push to Testing" button for both. It might be a good idea to check for the existence of other such zombie updates, although maybe I was the only fool actually building packages while the bodhi activation was taking place. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proven packager help request: DCMTK (and dependent packages) require update in F29/F30
On Fri, Sep 13, 2019 23:20:50 +0900, Mamoru TASAKA wrote: > Ankur Sinha wrote on 2019/09/13 23:07: > Well, actually some google search result is that the actual fix seems > https://github.com/commontk/DCMTK/commit/40917614e > and the tracker is > https://support.dcmtk.org/redmine/issues/858 > > ref: https://nvd.nist.gov/vuln/detail/CVE-2019-1010228 > > So it seems if the above patch only can be applied, no rebuild is > needed. Sure, I could do that---would that be the suggested thing to do? Given that we have evidence that the dependent tools build properly, this is a low risk update. So, I was hoping to update to the current version to also give users the advantage of other fixes/enhancements than carry a patch for the one fix---especially for F30 which still has quite a life to live. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: Possibly unresponsive maintainer: vakwetu
On Fri, 2019-09-13 at 18:51 +0200, Miro Hrončok wrote: > On 13. 09. 19 16:33, Dinesh Prasanth Moluguwan Krishnamoorthy wrote: > > Currently, the members of the dogtag team own this package. > > Not correct, it is still owned by vakwetu. Let me take back my words and rephrase. Dogtag team maintains this package, currently. I will request Ade to transfer the "Main Admin" access to one of the members of the Dogtag team. Regards, --Dinesh > > -- > 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 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: Donate 1 minute of your time to test upgrades from F29 to F30
Il giorno gio, 28/02/2019 alle 10.22 +0100, Miroslav Suchý ha scritto: > Do you want to make Fedora 30 better? Please spend 1 minute of your > time and try to run: > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the real > upgrade. Upgrades will be fine for you. > > But very likely you get some dependency problem now. In that case > please report it against appropriate package. > > Thank you > > Miroslav I got this: Errore: Problema: problem with installed package rubygem-asciidoctor-pdf- 1.5.0-0.9.alpha.16.fc30.noarch - rubygem-asciidoctor-pdf-1.5.0-0.9.alpha.16.fc30.noarch does not belong to a distupgrade repository - nothing provides (rubygem(concurrent-ruby) >= 1.1.0 with rubygem(concurrent-ruby) < 1.2) needed by rubygem-asciidoctor-pdf- 1.5.0-0.10.alpha.18.fc31.noarch - nothing provides (rubygem(treetop) >= 1.5.0 with rubygem(treetop) < 1.6) needed by rubygem-asciidoctor-pdf-1.5.0-0.10.alpha.18.fc31.noarch (try to add '--skip-broken' to skip uninstallable packages) Ciao Guido ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Donate 1 minute of your time to test upgrades from F30 to F31
Il giorno mer, 11/09/2019 alle 14.54 +0200, Miroslav Suchý ha scritto: > Do you want to make Fedora 31 better? Please spend 1 minute of your > time and try to run [*]: > > sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31 > --enablerepo=updates-testing distro-sync > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the actual > upgrade. > > But very likely you get some dependency problem now. In that case, > please report it against the appropriate package. Or > against fedora-obsolete-packages if that package should be removed in > Fedora 31. Please check existing reports first: > https://red.ht/2kuBDPu > > Thank you > > [*] this command does not replace `dnf system-upgrade`, but it will > reveal potential problems. You may also run `dnf > upgrade` before running this command. > > -- > Miroslav Suchy, RHCA > Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys I got this: Errore: Problema: problem with installed package rubygem-asciidoctor-pdf- 1.5.0-0.9.alpha.16.fc30.noarch - rubygem-asciidoctor-pdf-1.5.0-0.9.alpha.16.fc30.noarch does not belong to a distupgrade repository - nothing provides (rubygem(concurrent-ruby) >= 1.1.0 with rubygem(concurrent-ruby) < 1.2) needed by rubygem-asciidoctor-pdf- 1.5.0-0.10.alpha.18.fc31.noarch - nothing provides (rubygem(treetop) >= 1.5.0 with rubygem(treetop) < 1.6) needed by rubygem-asciidoctor-pdf-1.5.0-0.10.alpha.18.fc31.noarch (try to add '--skip-broken' to skip uninstallable packages) Ciao Guido P.S. Sorry for the wrong answer to wrong Fedora version ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Need help: SWIG related build error for python-pivy?
I can put the packages somewhere online but you have to build the whole
chain... I'll try a little longer to manage it here and if you need more
info maybe I'll setup a COPR...
Looking at a section of the file and line number from the error I see the
following, with the line in question (73) being the "class SOQT_DLL_API"
line:
#include
#include
class SoEvent;
// *
class SOQT_DLL_API SoQtDevice : public SoQtObject {
SOQT_OBJECT_ABSTRACT_HEADER(SoQtDevice, SoQtObject);
public:
virtual ~SoQtDevice();
virtual void enable(QWidget* w, SoQtEventHandler * handler, void *
closure) = 0;
virtual void disable(QWidget* w, SoQtEventHandler * handler, void *
closure) = 0;
virtual const SoEvent * translateEvent(QEvent* event) = 0;
void setWindowSize(const SbVec2s size);
SbVec2s getWindowSize(void) const;
static void initClasses(void);
protected:
SoQtDevice(void);
void setEventPosition(SoEvent * event, int x, int y) const;
static SbVec2s getLastEventPosition(void);
void addEventHandler(QWidget*, SoQtEventHandler *, void *);
void removeEventHandler(QWidget*, SoQtEventHandler *, void *);
void invokeHandlers(QEvent* event);
private:
class SoQtDeviceP * pimpl;
friend class SoQtDeviceP;
};
I also ran a diff from the same Pivy compiled with Coin3 and Coin4 and the
ONLY significant difference is where the asterisk is on the QWidget lines:
Coin3: ...(QWidget *...
Coin4: ...(QWidget*...
Does the space between QWidget and asterisk make a difference?
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: DNF system-upgrade instructions on docs.fp.o
Hello, If there are no objections, I shall file a ticket with infra to redirect https://fedoraproject.org/wiki/DNF_system_upgrade to https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ sometime after Wednesday, 18th September, 1200 BST(UTC+1). -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
[Test-Announce] 2019-09-16 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2019-09-16 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We just signed off on the Beta, so let's check in and catch up on things we missed last week. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 31 status 3. Automatic blockers vs. 'last minute' blockers: FIGHT 4. Test Day / community event status 5. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
[Test-Announce] 2019-09-16 @ 16:00 UTC - Fedora 31 Blocker Review Meeting
# F31 Blocker Review meeting # Date: 2019-09-16 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 7 proposed Final blockers and 1 proposed Final freeze exception to review, so let's have a Fedora 31 blocker review meeting on Monday! If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F31 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Fedora 31 Final blocker status email #1
Beta is go! Time to shift our focus to the final blockers, of which there are a few. Action summary Accepted blockers - 1. gnome-control-center — can't turn zoom off once enabled — NEW ACTION: upstream to diagnose and fix issue 2. gnome-control-center — Gnome Control Center crashes upon a typo in Printers settings — NEW ACTION: maintainer to diagnose and fix issue 3. kde — Needs updating for Fedora 31 background etc — MODIFIED ACTION: QA to verify fixed package 4. LiveCD — Workstation x86_64 live image is over size target — NEW ACTION: Workstation WG to trim installed packages or revisit size limit 5. sddm — Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine — NEW ACTION: sddm maintainers to diagnose issue Proposed blockers - 1. gnome-control-center — Apply button stays gray on Network configuration — NEW ACTION: maintainer to diagnose and fix issue 2. gnome-session — Second user gets locked out of his session every ~10 seconds — NEW ACTION: maintainer to diagnose and fix issue 3. gnome-software — GNOME Software doesn't prepare offline updates — NEW ACTION: FESCo to vote on reverting "Set skip_if_unavailable default to false" change 4. libgit2 — Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed — NEW ACTION: someone(!) to figure out a way to handle cases where previously-installed modules block non-modular package installation 5. selinux-policy — Problem with time syncronization — ASSIGNED ACTION: maintainers to diagnose and fix issue 6. webkit2gtk3 — gnome-initial-setup: webkitWebViewBaseMakeGLContextCurrent(): gnome-initial-setup killed by SIGSEGV — NEW ACTION: maintainers to diagnose and fix issue 7. xfdesktop — Xfce is using upstream desktop background — ASSIGNED ACTION: maintainers to figure out why updating the sed command does not correctly replace the desktop background Bug-by-bug detail = Accepted blockers - 1. gnome-control-center — https://bugzilla.redhat.com/show_bug.cgi?id=1749433 — NEW can't turn zoom off once enabled Zoom remains enabled, even after logging out and logging back in. Issue filed upstream: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/659 2. gnome-control-center — https://bugzilla.redhat.com/show_bug.cgi?id=1750394 — NEW Gnome Control Center crashes upon a typo in Printers settings Typo in search field (e.g. 'socket>' instead of 'socket:') causes application to crash. 3. kde — https://bugzilla.redhat.com/show_bug.cgi?id=1749086 — NEW Needs updating for Fedora 31 background etc. Original fix used upstream background. Update FEDORA-2019-6004dba64a should fix this. 4. LiveCD — https://bugzilla.redhat.com/show_bug.cgi?id=1751438 — NEW Workstation x86_64 live image is over size target Adding podman increased the size of the live image above the specified maximum. Either some packages need to be removed from the image or the Workstation WG needs to increase the maximum size. 5. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1728240 — NEW Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine This issue only seems to affect BIOS machines when using basic graphics mode. Regular graphics or UEFI does not exhibit this behavior. Proposed blockers - 1. gnome-control-center — https://bugzilla.redhat.com/show_bug.cgi?id=1750805 — NEW Apply button stays gray on Network configuration Wired network connections cannot be configured because the "apply" button remains inactive. WiFi configuration works. 2. gnome-session — https://bugzilla.redhat.com/show_bug.cgi?id=1751673 — NEW Second user gets locked out of his session every ~10 seconds When user1 is already logged into GNOME, locks his session, and user2 logs in, user2's screen is locked immediately after logging in. When user2 keeps logging in, his screen is lo cked approximately every 10 seconds. The locked screen shows user1's name (so not only user2 is locked, the screen also switches to user1's lock screen every time). 3. gnome-session — https://bugzilla.redhat.com/show_bug.cgi?id=1749868 — NEW GNOME Software doesn't prepare offline updates Systems with third-party repos that are not functional fail. This is a result of an accepted F31 Change (https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_ false). FESCo is voting whether or not to revert it (https://pagure.io/fesco/issue/2125) 4. libgit2 — https://bugzilla.redhat.com/show_bug.cgi?id=1747408 — NEW Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed dnf prevents installation of a non-modular package when the package is already installed as a module. Resetting the libgit2 module in fedora-obsolete-packages (F30) would fix this issue, but can break systems with explictly s
Re: Possibly unresponsive maintainer: vakwetu
On 13. 09. 19 20:10, Dinesh Prasanth Moluguwan Krishnamoorthy wrote: I will request Ade to transfer the "Main Admin" access to one of the members of the Dogtag team. Thank you. -- 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
Self Introduction: Joshua Cogliati
FAS: jrincayc My day job includes programming in Java, Python, C++ and Fortran. I have been using Fedora since it branched from Redhat Linux. I have submitted various patches to other open source projects including GCC, Python, LibreOffice and several games. I wrote a python tutorial called the non-programmer's python tutorial that some people have found useful ( http://jjc.freeshell.org/easytut3/easytut3/ ). I submitted my first package review request today for ucblogo (which used to be in Fedora but has been FTBFS since Fedora 27): https://bugzilla.redhat.com/show_bug.cgi?id=1752139 Joshua Cogliati 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
Re: Proven packager help request: DCMTK (and dependent packages) require update in F29/F30
Ankur Sinha wrote on 2019/09/14 2:58: On Fri, Sep 13, 2019 23:20:50 +0900, Mamoru TASAKA wrote: Ankur Sinha wrote on 2019/09/13 23:07: Well, actually some google search result is that the actual fix seems https://github.com/commontk/DCMTK/commit/40917614e and the tracker is https://support.dcmtk.org/redmine/issues/858 ref: https://nvd.nist.gov/vuln/detail/CVE-2019-1010228 So it seems if the above patch only can be applied, no rebuild is needed. Sure, I could do that---would that be the suggested thing to do? Given that we have evidence that the dependent tools build properly, this is a low risk update. So, I was hoping to update to the current version to also give users the advantage of other fixes/enhancements than carry a patch for the one fix---especially for F30 which still has quite a life to live. As written on https://fedoraproject.org/wiki/Updates_Policy#Philosophy updates should aim to fix bugs and not to introduce features. And changing ABI is discouraged unless avoided. Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Cannot add a user to a package as a comaintainer
Hello! I've just stumbled with a problem - I've sponsored a person to packagers group (several hours ago) but still cannot add that person as a comaintainer using account's name in src.fedoraproject.org. Did I miss something or I just need to wait a bit more? -- With best regards, Peter Lemenkov. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
