Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, 25 Nov 2019 22:59:18 +0100, Samuel Sieb wrote: > I don't understand why this change is > necessary at all. It only affects local logins and if someone wants to have > an empty password, why make it so difficult? It's their choice. It's not > like Fedora has any default logins with empty passwords, the user has to > make their own. Yes, what about firewalled virtual machines for development testing purposes? There any password makes no sense. Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-30-20191126.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Mondays's FESCo Meeting (2019-11-25)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-11-25 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Title of issue https://pagure.io/fesco/issue/### DECISION (+X, Y, -Z) #2284 Adapt the Updates policy for Rawhide gating https://pagure.io/fesco/issue/2284 APPROVED (+6, 0, 0) bookwar will work on a PR. #2282 Non-responsive maintainer: weli https://pagure.io/fesco/issue/2282 APPROVED: we orphan the packages immediately (+3,0,-0) #2278 Python2 exception for git-remote-hg https://pagure.io/fesco/issue/2278 APPROVED (+5,0,-0) #2275 Python2 exception for NFStest https://pagure.io/fesco/issue/2275 APPROVED (+6,0,-0) #2274 Python2 exception for offlineimap https://pagure.io/fesco/issue/2274 APPROVED (+4,1,-0) #2269 F32 System-Wide Change: iptables-nft-default https://pagure.io/fesco/issue/2269 APPROVED (+3,1,-0) = Followups = #2285 Make Eclipse Installable https://pagure.io/fesco/issue/2285 = New business = = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-29-20191125.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-29-20191124.0): ID: 488105 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/488105 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-31-20191125.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Taking over munge; use scitech group on FAS to share package maintenance tasks? (Re: [Scitech] Re: OpenMPI stack in danger)
On Mon, Nov 25, 2019 07:29:39 -0700, Orion Poplawski wrote: > > > Sure---if everyone is aboard this plan (Cc'd orion, who is the owner of > > the group), how should we do this? There's a FAS group for scitech > > already. Is this being used for anything currently? If not, we can > > clean this out and request that it be converted to a packager group. > > > > https://admin.fedoraproject.org/accounts/group/members/scitech/ > > Currently it handles permissions for the scitech copr group. I'm not sure > why this would need to be cleaned out before converting to a package group. From what I understand, once the scitech FAS group turns into a packager group, only folks that are in the packager group can also be part of this one. So, if all current members are already packagers, we don't need to do anything. If the current group has folks that are not in packagers, they will either need to be sponsored there or removed from the scitech group. > I'd be happy to see it become a packager group. Great, thanks. I filed an issue with infra here: https://pagure.io/fedora-infrastructure/issue/8413 -- 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: Taking over munge; use scitech group on FAS to share package maintenance tasks? (Re: [Scitech] Re: OpenMPI stack in danger)
On 11/25/19 5:50 AM, Ankur Sinha wrote: On Mon, Nov 25, 2019 13:26:20 +0100, Dominik 'Rathann' Mierzejewski wrote: On Monday, 25 November 2019 at 12:45, Ankur Sinha wrote: On Mon, Nov 25, 2019 11:38:42 +0100, Dominik 'Rathann' Mierzejewski wrote: Hi! To save time looking this up, I want to direct the attention of pmix and openmpi maintainers (Cc'd) to this chain: munge (orphaned) -> pmix -> openmpi In short, anything that depends on openmpi is at risk of being retired. https://src.fedoraproject.org/rpms/pmix says it's owned by pkfed at the moment. So is this sorted? Otherwise I can take it up to keep it alive (and the NeuroFedora team can help maintain it). No. pmix is not orphaned, but munge is. I checked upstream and the last release is over 2 years old, but the last commit at github is from May this year, so it looks like upstream is still alive. I don't have time to take up yet another package, though. Ugh, Sorry! I read that wrong XD I've requested ownership of `munge` now: https://pagure.io/releng/issue/9052 Should we perhaps have a FAS packager group for scitech too, so we can help maintain packages as a team? Would that help? We do this for the NeuroSIG[1] and it works quote well. Yes, it's a good idea. Would you be willing to take care of that? Sure---if everyone is aboard this plan (Cc'd orion, who is the owner of the group), how should we do this? There's a FAS group for scitech already. Is this being used for anything currently? If not, we can clean this out and request that it be converted to a packager group. https://admin.fedoraproject.org/accounts/group/members/scitech/ Currently it handles permissions for the scitech copr group. I'm not sure why this would need to be cleaned out before converting to a package group. I'd be happy to see it become a packager group. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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
Review swap: virt-v2v
* https://bugzilla.redhat.com/show_bug.cgi?id=1774713 Review Request: virt-v2v - Convert a virtual machine to run on KVM This is actually more of a package split. This program was part of libguestfs, but has been split out into a separate upstream project: https://github.com/libguestfs/libguestfs/commit/85c99edec19ac7afb38fa6003e35f51db143922c https://github.com/libguestfs/virt-v2v and removed from the Fedora libguestfs package: https://src.fedoraproject.org/rpms/libguestfs/c/85c51621ab836847051f59cc4c943025b4bd8f89?branch=master Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Do we need a "No broken deps" Objective?
On Mon, Nov 25, 2019 at 2:08 PM Igor Gnatenko wrote: > > Hey Fabio, Hey Igor! > There is a problem with the code. You seem to run either repoquery or > repoclosure inside. However, that does not really check rich > dependencies correctly. Yes, I know, I'm using repoclosure. Sadly, fixing DNF's handling of some rich deps is outside my area of expertise ;) But I can whitelist rich deps that are actually satisfiable in fedora (as I started to do for some things that I know are actually satisfiable). > Do you want to check for FTI/FTBFS or that all dependencies are > present in Fedora? FTI <=> (missing dependencies in binary package and/or conflicting deps) FTBFS <=> (missing dependencies in source package and/or actually fails to build for other reasons) Checking FTI caused by conflicting dependencies is outside the scope of my checks for now, and checking FTBFS issues is already covered elsewhere. So for now, I'm only checking for missing/broken dependencies. Fabio > On Mon, Nov 25, 2019 at 1:23 PM Fabio Valentini wrote: > > > > Hi everybody, > > > > I'm a bit concerned about the growing number of broken dependencies in > > fedora, which leads to non-installable (FTI) and un-buildable (FTBFS) > > packages. For rawhide [0], I see almost 400 source packages and almost > > 200 x86_64 packages with broken deps. Especially the number of source > > packages with broken dependencies has steadily been growing since 29. > > > > With a bit of effort, a lot of these broken packages could be fixed > > quite easily, but it would still need a coordinated effort by a group > > of people. I think an Objective would fit for that purpose. > > > > Fabio > > > > PS: Feel free to browse the data in the linked pagure repo. I'm > > regenerating it daily with the latest state of all fedora branches. If > > somebody is interested in getting notified about any of their packages > > getting broken deps (for example, in -testing, before things get > > broken in stable), I can work out some kind of automatic (opt-in) > > notification system :) > > > > [0]: > > https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/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
Summary/Minutes from today's FESCo Meeting (2019-11-25)
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-25/fesco.2019-11-25-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-25/fesco.2019-11-25-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-25/fesco.2019-11-25-15.00.log.html Meeting summary --- * init process (zbyszek, 15:00:45) * #2285 Make Eclipse Installable (zbyszek, 15:01:51) * LINK: https://pagure.io/fm-orchestrator/pull-request/1526#request_diff (zbyszek, 15:02:09) * There were not enough votes to decide the matter. We'll continue voting in the ticket. (zbyszek, 15:26:07) * Next week's chair (zbyszek, 15:26:10) * ACTION: jforbes will chair next meeting. (zbyszek, 15:26:39) * Open Floor (zbyszek, 15:26:45) Meeting ended at 15:28:50 UTC. Action Items * jforbes will chair next meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Question about mass rebuilds
I have a general question about mass rebuilds - I noticed that my F31 machine still has a few packages that appear to be fc30 versions, and I got curious as to why. For example, I have avr-libc-2.0.0-7.fc30.noarch installed. It has a build date of Thu 31 Jan 2019 09:23:34 AM EST I looked at the list of packages needing a rebuild for F31. As of the run on 2019-08-20 20:46:01.547095 UTC, avr-libc was listed: https://kojipkgs.fedoraproject.org/mass-rebuild/f31-need-rebuild.html Yet according to koji, there is no build for fc31: https://koji.fedoraproject.org/koji/packageinfo?packageID=avr-libc I'm not saying that anything is wrong - I'm just curious as to why the package wasn't rebuilt. Any guidance/info would be appreciated. Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Development Tools problems for build from source Krita.
Cătălin George Feștilă wrote: > I install 'Development Tools', but some tools are not in this group and > PythonLibrary is not set. Any idea how to fix it? dnf group install See below, the biggest missing piece is ECM, I'd suggest you do: sudo dnf builddep krita then you'll get everything that fedora's packaged krita builds against. If you're missing ECM, you're likely missing a lot of other stuff too. -- Rex > -- Krita version: 4.2.8-beta1 > -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.5", > minimum required is "3.0") -- Python system site-packages directory: > /usr/lib64/python3.7/site-packages -- Could NOT find PythonLibrary > (missing: PYTHON_LIBRARY) (Required is at least version "3.0") CMake Error > at CMakeLists.txt:253 (find_package): > By not providing "FindECM.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by "ECM", but > CMake did not find one. > > Could not find a package configuration file provided by "ECM" (requested > version 5.22) with any of the following names: > > ECMConfig.cmake > ecm-config.cmake > > Add the installation prefix of "ECM" to CMAKE_PREFIX_PATH or set > "ECM_DIR" > to a directory containing one of the above files. If "ECM" provides a > separate development package or SDK, be sure it has been installed. > > > -- Configuring incomplete, errors occurred! > See also "/home/mythcat/krita-4.2.8-beta1/CMakeFiles/CMakeOutput.log". > See also "/home/mythcat/krita-4.2.8-beta1/CMakeFiles/CMakeError.log". > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
OpenMPI stack in danger (Re: Orphaned packages looking for new maintainers)
Hi! On Monday, 25 November 2019 at 10:52, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via releng issues: > https://pagure.io/releng/issues > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2019-11-25.txt > grep it for your FAS username and follow the dependency chain. To save time looking this up, I want to direct the attention of pmix and openmpi maintainers (Cc'd) to this chain: munge (orphaned) -> pmix -> openmpi In short, anything that depends on openmpi is at risk of being retired. > Package (co)maintainers Status > Change > [...] > munge orphan 1 weeks ago [...] 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: [Scitech] OpenMPI stack in danger (Re: Orphaned packages looking for new maintainers)
On Mon, Nov 25, 2019 11:38:42 +0100, Dominik 'Rathann' Mierzejewski wrote: > Hi! > > > > To save time looking this up, I want to direct the attention of pmix and > openmpi maintainers (Cc'd) to this chain: > > munge (orphaned) -> pmix -> openmpi > > In short, anything that depends on openmpi is at risk of being retired. https://src.fedoraproject.org/rpms/pmix says it's owned by pkfed at the moment. So is this sorted? Otherwise I can take it up to keep it alive (and the NeuroFedora team can help maintain it). Should we perhaps have a FAS packager group for scitech too, so we can help maintain packages as a team? Would that help? We do this for the NeuroSIG[1] and it works quote well. [1] https://src.fedoraproject.org/group/neuro-sig -- 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
Do we need a "No broken deps" Objective?
Hi everybody, I'm a bit concerned about the growing number of broken dependencies in fedora, which leads to non-installable (FTI) and un-buildable (FTBFS) packages. For rawhide [0], I see almost 400 source packages and almost 200 x86_64 packages with broken deps. Especially the number of source packages with broken dependencies has steadily been growing since 29. With a bit of effort, a lot of these broken packages could be fixed quite easily, but it would still need a coordinated effort by a group of people. I think an Objective would fit for that purpose. Fabio PS: Feel free to browse the data in the linked pagure repo. I'm regenerating it daily with the latest state of all fedora branches. If somebody is interested in getting notified about any of their packages getting broken deps (for example, in -testing, before things get broken in stable), I can work out some kind of automatic (opt-in) notification system :) [0]: https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [Scitech] OpenMPI stack in danger (Re: Orphaned packages looking for new maintainers)
On Monday, 25 November 2019 at 12:45, Ankur Sinha wrote: > On Mon, Nov 25, 2019 11:38:42 +0100, Dominik 'Rathann' Mierzejewski wrote: > > Hi! > > > > > > > > To save time looking this up, I want to direct the attention of pmix and > > openmpi maintainers (Cc'd) to this chain: > > > > munge (orphaned) -> pmix -> openmpi > > > > In short, anything that depends on openmpi is at risk of being retired. > > https://src.fedoraproject.org/rpms/pmix says it's owned by pkfed at the > moment. So is this sorted? Otherwise I can take it up to keep it alive > (and the NeuroFedora team can help maintain it). No. pmix is not orphaned, but munge is. I checked upstream and the last release is over 2 years old, but the last commit at github is from May this year, so it looks like upstream is still alive. I don't have time to take up yet another package, though. > Should we perhaps have a FAS packager group for scitech too, so we can > help maintain packages as a team? Would that help? We do this for the > NeuroSIG[1] and it works quote well. Yes, it's a good idea. Would you be willing to take care of that? 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: Orphaned packages looking for new maintainers
On Mon, Nov 25, 2019 at 11:32 AM Sandro Bonazzola wrote: > > > > Il giorno lun 25 nov 2019 alle ore 10:54 Miro Hrončok > ha scritto: >> >> The following packages are orphaned and will be retired when they >> are orphaned for six weeks, unless someone adopts them. If you know for sure >> that the package should be retired, please do so now with a proper reason: >> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life >> >> Note: If you received this mail directly you (co)maintain one of the affected >> packages or a package that depends on one. Please adopt the affected package >> or >> retire your depending package to avoid broken dependencies, otherwise your >> package will be retired when the affected package gets retired. >> >> Request package ownership via releng issues: >> https://pagure.io/releng/issues >> >> Full report available at: >> https://churchyard.fedorapeople.org/orphans-2019-11-25.txt >> grep it for your FAS username and follow the dependency chain. >> >> Package (co)maintainers Status >> Change >> >> ExchangeIRorphan 1 weeks >> ago >> FUR orphan 2 weeks >> ago >> airsnort orphan 2 weeks >> ago >> apache-logging-parent mizdebsk, orphan 1 weeks >> ago >> apache-mime4j orphan 4 weeks >> ago >> apt-cacher-ng orphan 1 weeks >> ago >> archaius orphan 1 weeks >> ago >> archmage lbazan, orphan 0 weeks >> ago >> audit-viewer mitr, orphan 0 weeks >> ago >> avalon-logkit jerboaa, mizdebsk, orphan0 weeks >> ago >> base64coder jcapik, mizdebsk, orphan 2 weeks >> ago >> batik jvanek, mizdebsk, orphan 2 weeks >> ago >> buildnumber-maven-plugin orphan 0 weeks >> ago >> bval orphan 1 weeks >> ago >> camotics orphan 1 weeks >> ago >> cduce orphan 1 weeks >> ago >> clapham orphan 1 weeks >> ago >> classmate lef, orphan 3 weeks >> ago >> cli-parserlef, orphan 3 weeks >> ago >> csstidy orphan 1 weeks >> ago >> delve go-sig, orphan 1 weeks >> ago >> dillo aarem, orphan2 weeks >> ago >> eclipse-anyedit eclipse-sig, orphan, swagiaal1 weeks >> ago >> eclipse-avr orphan 1 weeks >> ago >> eclipse-cdt akurtakov, eclipse-sig, 4 weeks >> ago >>jjohnstn, kdaniel, orphan, >>rgrunber >> eclipse-checkstyleakurtakov, eclipse-sig, orphan 1 weeks >> ago >> eclipse-color-theme eclipse-sig, orphan 1 weeks >> ago >> eclipse-dltk akurtakov, eclipse-sig, 1 weeks >> ago >>kdaniel, orphan, rgrunber >> eclipse-egit akurtakov, arobinso, eclipse-1 weeks >> ago >>sig, jerboaa, jjohnstn, >>kdaniel, nguzman, orphan, >>rgrunber >> eclipse-emf akurtakov, eclipse-sig, 1 weeks >> ago >>jjohnstn, kdaniel, orphan, >>rgrunber >> eclipse-epic eclipse-sig, orphan 1 weeks >> ago >> eclipse-gef akurtakov, eclipse-sig, 1 weeks >> ago >>kdaniel, orphan, rgrunber >> eclipse-launchbar eclipse-sig, orphan, sopotc 3 weeks >> ago >> eclipse-license eclipse-sig, orphan 1 weeks >> ago >> eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan1 weeks >> ago >> eclipse-m2e-apt eclipse-sig, orphan 1 weeks >> ago >> eclipse-m2e-buildhelper eclipse-sig, mizdebsk, orphan1 weeks >> ago >> eclipse-m2e-core eclipse-sig, galileo,1 weeks >> ago >>
Re: pdfbox and batik (was: Re: [fedora-java] What's the State of the Java SIG?)
On Mon, Nov 25, 2019 at 12:31 PM Kevin Kofler wrote: > As an example of the sorry state of the Java SIG, pdfbox and batik were > orphaned 2 weeks ago, but those are dependencies of fop, which is a > dependency of publican, which is used by appstream to build documentation, > and half of the distribution (including the entire KF5 stack, through > extra- > cmake-modules) depends on appstream. > > Java is not an isolated island (despite its name ;-) ). Most Java stuff > can > be done without (and upstream JARs used instead), but the dependencies of > non-Java packages MUST be taken care of by somebody. > The world is still waiting for the next Java hero to appear :( . > > 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 > -- Alexander Kurtakov Red Hat Eclipse Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Minimization Objective report
On Tue, Nov 19, 2019 at 8:22 PM Adam Jackson wrote: > On Fri, 2019-11-15 at 23:38 +0100, Kevin Kofler wrote: > > Adam Samalik wrote: > > > 1/ A history chart for base images [2] is now being generated — > includes > > > data since 25 September. It's a bit rough initial implementation, but > it's > > > there! > > > > Almost 2 months of work to save… 0.5%! That does not look like a huge > > success to me. You simply cannot win against the creeping bloat. :-( > > Ahem. > > In the spirit of positivity and collaboration, I spent a few minutes > looking at the results given to try to find some easy wins. Here's what > I found: > > python3-libs ships multiple copies of its pyc files, corresponding to > different optimization levels. I don't know what a good packaging > solution to that would look like, but if we only shipped the -O2 kind > (which seems appropriate for minimization, as they're smallest) we > could drop about 13M out of 32M, which seems pretty great. > > About 2/3 of glib2 is translations. If it was langpacked like glibc you > could drop another 8M. Likewise about 9M out of 10M for coreutils- > common, 4.5 out of 7.5 for bash, 4 out of 10 for gnupg2. > > You're not using coreutils-single, which would save you another 6M or > so. > > It's hard to understand why dejavu-sans-fonts is in there, since there > are zero font libraries installed in the container base. Probably > that's brought in by the langpacks somewhere along the line, but it > seems like fonts and translations should be logically separate here (no > point installing fonts if you're not going to be printing or making > images, right?). That's another 5.5M. > > That's about 44M worth of potential savings out of a 204M base image, a > bit over 20%. I'll happily file proper bug reports for these somewhere > if we want, but it took me like 30 minutes to look into this. If you're > not even willing to put in _that_ little effort, then forgive me for > not taking your assertion that "you simply cannot win" very seriously. > Hey Adam, Thanks for looking into that. If you could file those bugs that would be fantastic. I'm sure we can win if there are enough eyes looking for improvements :-) Especially if we have tooling / services that will help us to _keep_ things over time. Cheers, Adam > > - ajax > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Adam Šamalík --- Senior Software Engineer Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 looking for new maintainers
Il giorno lun 25 nov 2019 alle ore 10:54 Miro Hrončok ha scritto: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the > affected > packages or a package that depends on one. Please adopt the affected > package or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via releng issues: > https://pagure.io/releng/issues > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2019-11-25.txt > grep it for your FAS username and follow the dependency chain. > > Package (co)maintainers Status > Change > > > ExchangeIRorphan 1 weeks > ago > FUR orphan 2 weeks > ago > airsnort orphan 2 weeks > ago > apache-logging-parent mizdebsk, orphan 1 weeks > ago > apache-mime4j orphan 4 weeks > ago > apt-cacher-ng orphan 1 weeks > ago > archaius orphan 1 weeks > ago > archmage lbazan, orphan 0 weeks > ago > audit-viewer mitr, orphan 0 weeks > ago > avalon-logkit jerboaa, mizdebsk, orphan0 weeks > ago > base64coder jcapik, mizdebsk, orphan 2 weeks > ago > batik jvanek, mizdebsk, orphan 2 weeks > ago > buildnumber-maven-plugin orphan 0 weeks > ago > bval orphan 1 weeks > ago > camotics orphan 1 weeks > ago > cduce orphan 1 weeks > ago > clapham orphan 1 weeks > ago > classmate lef, orphan 3 weeks > ago > cli-parserlef, orphan 3 weeks > ago > csstidy orphan 1 weeks > ago > delve go-sig, orphan 1 weeks > ago > dillo aarem, orphan2 weeks > ago > eclipse-anyedit eclipse-sig, orphan, swagiaal1 weeks > ago > eclipse-avr orphan 1 weeks > ago > eclipse-cdt akurtakov, eclipse-sig, 4 weeks > ago >jjohnstn, kdaniel, orphan, >rgrunber > eclipse-checkstyleakurtakov, eclipse-sig, orphan 1 weeks > ago > eclipse-color-theme eclipse-sig, orphan 1 weeks > ago > eclipse-dltk akurtakov, eclipse-sig, 1 weeks > ago >kdaniel, orphan, rgrunber > eclipse-egit akurtakov, arobinso, eclipse-1 weeks > ago >sig, jerboaa, jjohnstn, >kdaniel, nguzman, orphan, >rgrunber > eclipse-emf akurtakov, eclipse-sig, 1 weeks > ago >jjohnstn, kdaniel, orphan, >rgrunber > eclipse-epic eclipse-sig, orphan 1 weeks > ago > eclipse-gef akurtakov, eclipse-sig, 1 weeks > ago >kdaniel, orphan, rgrunber > eclipse-launchbar eclipse-sig, orphan, sopotc 3 weeks > ago > eclipse-license eclipse-sig, orphan 1 weeks > ago > eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan1 weeks > ago > eclipse-m2e-apt eclipse-sig, orphan 1 weeks > ago > eclipse-m2e-buildhelper eclipse-sig, mizdebsk, orphan1 weeks > ago > eclipse-m2e-core eclipse-sig, galileo,1 weeks > ago >mizdebsk, orphan > eclipse-m2e-cxf eclipse-sig, mizdebsk, orphan1 weeks > ago > eclipse-m2e-egit eclipse-sig, mizdebsk, orphan1 weeks > ago >
Re: Orphaned packages looking for new maintainers
On 25. 11. 19 11:30, Sandro Bonazzola wrote: I believe above is wrong. I'm not maintaining buildnumber-maven-plugin package. You are not. You are maintaining something that is affected by buildnumber-maven-plugin being orphaned. See https://churchyard.fedorapeople.org/orphans-2019-11-25.txt Depending on: buildnumber-maven-plugin (27), status change: 2019-11-23 (0 weeks ago) ... nimbus-jose-jwt (maintained by: sbonazzo) nimbus-jose-jwt-5.12-5.fc31.src requires mvn(org.codehaus.mojo:buildnumber-maven-plugin) = 1.3 -- 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: Do we need a "No broken deps" Objective?
Hey Fabio, There is a problem with the code. You seem to run either repoquery or repoclosure inside. However, that does not really check rich dependencies correctly. Do you want to check for FTI/FTBFS or that all dependencies are present in Fedora? On Mon, Nov 25, 2019 at 1:23 PM Fabio Valentini wrote: > > Hi everybody, > > I'm a bit concerned about the growing number of broken dependencies in > fedora, which leads to non-installable (FTI) and un-buildable (FTBFS) > packages. For rawhide [0], I see almost 400 source packages and almost > 200 x86_64 packages with broken deps. Especially the number of source > packages with broken dependencies has steadily been growing since 29. > > With a bit of effort, a lot of these broken packages could be fixed > quite easily, but it would still need a coordinated effort by a group > of people. I think an Objective would fit for that purpose. > > Fabio > > PS: Feel free to browse the data in the linked pagure repo. I'm > regenerating it daily with the latest state of all fedora branches. If > somebody is interested in getting notified about any of their packages > getting broken deps (for example, in -testing, before things get > broken in stable), I can work out some kind of automatic (opt-in) > notification system :) > > [0]: > https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
Unannounced SONAME bump in libusbmuxd
FYI, commit [0] introduced a major update for libusbmuxd to rawhide (including an unannounced SONAME bump), and even explicitly changed the %files entry for the shared library against the Packaging Guidelines' recommendations to cover the library version with a glob. *frown* Please coordinate rebuilds with the maintainers of the affected packages (even if it's a bit late now) ... Fabio [0]: https://src.fedoraproject.org/rpms/libusbmuxd/c/0c3a98f196459741a2f8f7c3dd9b64cf68060cec?branch=master ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Taking over munge; use scitech group on FAS to share package maintenance tasks? (Re: [Scitech] Re: OpenMPI stack in danger)
On Mon, Nov 25, 2019 13:26:20 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 25 November 2019 at 12:45, Ankur Sinha wrote: > > On Mon, Nov 25, 2019 11:38:42 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > Hi! > > > > > > > > > > > > To save time looking this up, I want to direct the attention of pmix and > > > openmpi maintainers (Cc'd) to this chain: > > > > > > munge (orphaned) -> pmix -> openmpi > > > > > > In short, anything that depends on openmpi is at risk of being retired. > > > > https://src.fedoraproject.org/rpms/pmix says it's owned by pkfed at the > > moment. So is this sorted? Otherwise I can take it up to keep it alive > > (and the NeuroFedora team can help maintain it). > > No. pmix is not orphaned, but munge is. I checked upstream and the last > release is over 2 years old, but the last commit at github is from May > this year, so it looks like upstream is still alive. I don't have time > to take up yet another package, though. Ugh, Sorry! I read that wrong XD I've requested ownership of `munge` now: https://pagure.io/releng/issue/9052 > > Should we perhaps have a FAS packager group for scitech too, so we can > > help maintain packages as a team? Would that help? We do this for the > > NeuroSIG[1] and it works quote well. > > Yes, it's a good idea. Would you be willing to take care of that? Sure---if everyone is aboard this plan (Cc'd orion, who is the owner of the group), how should we do this? There's a FAS group for scitech already. Is this being used for anything currently? If not, we can clean this out and request that it be converted to a packager group. https://admin.fedoraproject.org/accounts/group/members/scitech/ -- 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
Orphaning infinispan from fedora
Hi all!. I orphaned infinispan package from fedora. Anyone of you guys know a reason why it shouldn't be orphaned? It is orphaned because no major packages depend on infinispan and it is also not in RHEL anymore (as I am RedHatter). If you do want to leave it in Fedora, will anyone of you became main admin? Thanks for answers! Ondrej Dubaj ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
pdfbox and batik (was: Re: [fedora-java] What's the State of the Java SIG?)
As an example of the sorry state of the Java SIG, pdfbox and batik were orphaned 2 weeks ago, but those are dependencies of fop, which is a dependency of publican, which is used by appstream to build documentation, and half of the distribution (including the entire KF5 stack, through extra- cmake-modules) depends on appstream. Java is not an isolated island (despite its name ;-) ). Most Java stuff can be done without (and upstream JARs used instead), but the dependencies of non-Java packages MUST be taken care of by somebody. 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
Re: pdfbox and batik
On 25. 11. 19 11:30, Kevin Kofler wrote: As an example of the sorry state of the Java SIG, pdfbox and batik were orphaned 2 weeks ago, but those are dependencies of fop, which is a dependency of publican, which is used by appstream to build documentation, and half of the distribution (including the entire KF5 stack, through extra- cmake-modules) depends on appstream. I've opened this a week ago: https://bugzilla.redhat.com/show_bug.cgi?id=1773385 -- 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
Taking over libgovirt (Re: Orphaned packages looking for new maintainers)
On Mon, Nov 25, 2019 at 6:55 AM Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the > affected > packages or a package that depends on one. Please adopt the affected > package or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via releng issues: > https://pagure.io/releng/issues > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2019-11-25.txt > grep it for your FAS username and follow the dependency chain. > > Package (co)maintainers Status > Change > > > ExchangeIRorphan 1 weeks > ago > FUR orphan 2 weeks > ago > airsnort orphan 2 weeks > ago > apache-logging-parent mizdebsk, orphan 1 weeks > ago > apache-mime4j orphan 4 weeks > ago > apt-cacher-ng orphan 1 weeks > ago > archaius orphan 1 weeks > ago > archmage lbazan, orphan 0 weeks > ago > audit-viewer mitr, orphan 0 weeks > ago > avalon-logkit jerboaa, mizdebsk, orphan0 weeks > ago > base64coder jcapik, mizdebsk, orphan 2 weeks > ago > batik jvanek, mizdebsk, orphan 2 weeks > ago > buildnumber-maven-plugin orphan 0 weeks > ago > bval orphan 1 weeks > ago > camotics orphan 1 weeks > ago > cduce orphan 1 weeks > ago > clapham orphan 1 weeks > ago > classmate lef, orphan 3 weeks > ago > cli-parserlef, orphan 3 weeks > ago > csstidy orphan 1 weeks > ago > delve go-sig, orphan 1 weeks > ago > dillo aarem, orphan2 weeks > ago > eclipse-anyedit eclipse-sig, orphan, swagiaal1 weeks > ago > eclipse-avr orphan 1 weeks > ago > eclipse-cdt akurtakov, eclipse-sig, 4 weeks > ago >jjohnstn, kdaniel, orphan, >rgrunber > eclipse-checkstyleakurtakov, eclipse-sig, orphan 1 weeks > ago > eclipse-color-theme eclipse-sig, orphan 1 weeks > ago > eclipse-dltk akurtakov, eclipse-sig, 1 weeks > ago >kdaniel, orphan, rgrunber > eclipse-egit akurtakov, arobinso, eclipse-1 weeks > ago >sig, jerboaa, jjohnstn, >kdaniel, nguzman, orphan, >rgrunber > eclipse-emf akurtakov, eclipse-sig, 1 weeks > ago >jjohnstn, kdaniel, orphan, >rgrunber > eclipse-epic eclipse-sig, orphan 1 weeks > ago > eclipse-gef akurtakov, eclipse-sig, 1 weeks > ago >kdaniel, orphan, rgrunber > eclipse-launchbar eclipse-sig, orphan, sopotc 3 weeks > ago > eclipse-license eclipse-sig, orphan 1 weeks > ago > eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan1 weeks > ago > eclipse-m2e-apt eclipse-sig, orphan 1 weeks > ago > eclipse-m2e-buildhelper eclipse-sig, mizdebsk, orphan1 weeks > ago > eclipse-m2e-core eclipse-sig, galileo,1 weeks > ago >mizdebsk, orphan > eclipse-m2e-cxf eclipse-sig, mizdebsk, orphan1 weeks > ago > eclipse-m2e-egit eclipse-sig, mizdebsk, orphan1 weeks > ago > eclipse-m2e-maven-dependency-
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via releng issues: https://pagure.io/releng/issues Full report available at: https://churchyard.fedorapeople.org/orphans-2019-11-25.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change ExchangeIRorphan 1 weeks ago FUR orphan 2 weeks ago airsnort orphan 2 weeks ago apache-logging-parent mizdebsk, orphan 1 weeks ago apache-mime4j orphan 4 weeks ago apt-cacher-ng orphan 1 weeks ago archaius orphan 1 weeks ago archmage lbazan, orphan 0 weeks ago audit-viewer mitr, orphan 0 weeks ago avalon-logkit jerboaa, mizdebsk, orphan0 weeks ago base64coder jcapik, mizdebsk, orphan 2 weeks ago batik jvanek, mizdebsk, orphan 2 weeks ago buildnumber-maven-plugin orphan 0 weeks ago bval orphan 1 weeks ago camotics orphan 1 weeks ago cduce orphan 1 weeks ago clapham orphan 1 weeks ago classmate lef, orphan 3 weeks ago cli-parserlef, orphan 3 weeks ago csstidy orphan 1 weeks ago delve go-sig, orphan 1 weeks ago dillo aarem, orphan2 weeks ago eclipse-anyedit eclipse-sig, orphan, swagiaal1 weeks ago eclipse-avr orphan 1 weeks ago eclipse-cdt akurtakov, eclipse-sig, 4 weeks ago jjohnstn, kdaniel, orphan, rgrunber eclipse-checkstyleakurtakov, eclipse-sig, orphan 1 weeks ago eclipse-color-theme eclipse-sig, orphan 1 weeks ago eclipse-dltk akurtakov, eclipse-sig, 1 weeks ago kdaniel, orphan, rgrunber eclipse-egit akurtakov, arobinso, eclipse-1 weeks ago sig, jerboaa, jjohnstn, kdaniel, nguzman, orphan, rgrunber eclipse-emf akurtakov, eclipse-sig, 1 weeks ago jjohnstn, kdaniel, orphan, rgrunber eclipse-epic eclipse-sig, orphan 1 weeks ago eclipse-gef akurtakov, eclipse-sig, 1 weeks ago kdaniel, orphan, rgrunber eclipse-launchbar eclipse-sig, orphan, sopotc 3 weeks ago eclipse-license eclipse-sig, orphan 1 weeks ago eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-apt eclipse-sig, orphan 1 weeks ago eclipse-m2e-buildhelper eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-core eclipse-sig, galileo,1 weeks ago mizdebsk, orphan eclipse-m2e-cxf eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-egit eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-maven-dependency- mizdebsk, orphan 1 weeks ago plugin eclipse-m2e-mavenarchiver eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-mavendev eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-modello eclipse-sig, mizdebsk, orphan1 weeks
Re: Fedora Atomic Host Nearing End Of Life
On 11/21/19 11:33 PM, Dusty Mabe wrote: This content also exists at: https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/ Last year we [introduced the plans for Fedora CoreOS] [1] including that Fedora CoreOS would be the successor to Fedora Atomic Host and Container Linux (from CoreOS Inc.). As part of that succession plan we decided that Fedora 29 Atomic Host would be the last stream of Fedora Atomic Host to be released. Fedora 29 Atomic Host has served us well, but with Fedora 29 End of Life coming soon [2], so will the last release of Fedora 29 Atomic Host. The next release of Fedora 29 Atomic Host (in the next few weeks) will be the last two-week release. It will contain all of the latest content from Fedora 29. After that release, Fedora 29, and Fedora 29 Atomic Host will no longer receive any updates. Please try out the Fedora CoreOS preview to help us get it towards stable. Documentation and download links can be found at https://getfedora.org/coreos/ The Atomic Host Team [1] https://fedoramagazine.org/announcing-fedora-coreos/ [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUK3CJ5LO4ROUH3JTCDVHYAVVYAOCU62/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Thanks for the info, But what about arches that are not x86_64 ? Where could we found for exemple the ppc64le coreos replacement of Atomic Host ? Is there already a web page to retrieve them ? -- Michel Normand ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 looking for new maintainers
* Miro Hrončok [25/11/2019 10:52] : > > perl-CGI-FormBuilder orphan 2 weeks ago This is maintained by ppisar, according to src.fedoraproject.org but Fedora Packages lists it as orphaned. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Open Babel 3.0.0
Hello Dominik, On Sun, Nov 24, 2019 at 7:40 PM Dominik Mierzejewski wrote: > > On Saturday, 23 November 2019 at 13:52, Alexander Ploumistos wrote: > [...] > > Now I'd argue that the changes in v3.0.0 would be worth bending the > > rules and updating everything in stable Fedora branches, but that is > > just unrealistic. Do you all think we could at least make it in time > > for f32? > > I think yes. Let's start a copr project for this. I don't have much > time right now, so go ahead and start one if you do. Otherwise I'll > get to it within the next few weeks. I'm in pretty much in the same situation time-wise, I will have some more time after 2-3 weeks, but I'll try to go over things during the weekends. > Link-time dependencies: […] > gnome-chemistry-utils This has been on life support for quite some time now, but I'm fairly optimistic, it always gets a band-aid when push comes to shove, albeit a bit late. At this moment I think there's also a bug when running on Wayland. > molsketch The patch for openbabel-3.0.0 is not yet merged, but it's getting there. > xdrawchem Last commit was a little under three years ago, it will probably require patching downstream. > Run-time dependencies: […] > chemtool More than 4 years since its last update, don't see that getting fixed upstream either. I'll try to do a more thorough research this weekend, which parts of openbabel are used by which program and also look at other distributions. Best regards, Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Do we need a "No broken deps" Objective?
On Mon, 2019-11-25 at 13:13 +0100, Fabio Valentini wrote: > Hi everybody, > > I'm a bit concerned about the growing number of broken dependencies in > fedora, which leads to non-installable (FTI) and un-buildable (FTBFS) > packages. For rawhide [0], I see almost 400 source packages and almost > 200 x86_64 packages with broken deps. Especially the number of source > packages with broken dependencies has steadily been growing since 29. I'd say the main problem here is not a lack of an objective but a lack of information. Back when the tooling still worked and we got a daily email with a handy list of packages with broken deps, I and Kevin Fenzi and others would regularly go through it and fix the ones we could fix, occasionally we'd get down to zero, but we always kept on top of it to some extent. Now there isn't a handy list any more, we just don't do this as much because it's not as easy to find what needs fixing in the first place. The most useful thing to do here would be to fix up the tooling so we get a reliable daily report again. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning js-jquery-file-upload
I have orphaned js-jquery-file-upload. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Review swap: virt-v2v
- Original Message - > > * https://bugzilla.redhat.com/show_bug.cgi?id=1774713 > Review Request: virt-v2v - Convert a virtual machine to run on KVM > > This is actually more of a package split. This program was part of > libguestfs, but has been split out into a separate upstream project: > > https://github.com/libguestfs/libguestfs/commit/85c99edec19ac7afb38fa6003e35f51db143922c > https://github.com/libguestfs/virt-v2v > > and removed from the Fedora libguestfs package: > > https://src.fedoraproject.org/rpms/libguestfs/c/85c51621ab836847051f59cc4c943025b4bd8f89?branch=master (Happened to notice this the first thing after I opened 'fedora-devel' in a while.) I'll take it; it's been a while since I reviewed a Fedora package, would be a good, quick refresher. [...] -- /kashyap ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Do we need a "No broken deps" Objective?
On Mon, Nov 25, 2019 at 5:14 AM Fabio Valentini wrote:
> PS: Feel free to browse the data in the linked pagure repo. I'm
> regenerating it daily with the latest state of all fedora branches. If
> somebody is interested in getting notified about any of their packages
> getting broken deps (for example, in -testing, before things get
> broken in stable), I can work out some kind of automatic (opt-in)
> notification system :)
This turned up a problem in the gap-pkg-polenta package, which I wish
I had known about sooner. So, yes, I am interested in some kind of
notification. I miss the old days when the broken deps report was
part of the Rawhide compose email. Is there any chance of bringing
that back? It was very useful.
The report lists the mscore package, which surprised me, since I just
built it a few days ago. It says:
- mscore (src):
o pkgconfig(Qt5WebEngine)
There is no problem installing 'pkgconfig(Qt5WebEngine)' in mock on my
machine. From the spec file:
%ifarch %{qt5_qtwebengine_arches}
BuildRequires: pkgconfig(Qt5WebEngine)
%endif
I suspect the check was run on a machine with an architecture not in
qt5_qtwebengine_arches. In that case, this is a false positive. Do
you have some way of telling when a BuildRequires is inside an %ifarch
or %ifnarch block?
Thanks for running this report, Fabio.
--
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: Do we need a "No broken deps" Objective?
On Mon, Nov 25, 2019 at 4:59 PM Jerry James wrote:
>
> On Mon, Nov 25, 2019 at 5:14 AM Fabio Valentini wrote:
> > PS: Feel free to browse the data in the linked pagure repo. I'm
> > regenerating it daily with the latest state of all fedora branches. If
> > somebody is interested in getting notified about any of their packages
> > getting broken deps (for example, in -testing, before things get
> > broken in stable), I can work out some kind of automatic (opt-in)
> > notification system :)
Hi Jerry!
> This turned up a problem in the gap-pkg-polenta package, which I wish
> I had known about sooner. So, yes, I am interested in some kind of
> notification. I miss the old days when the broken deps report was
> part of the Rawhide compose email. Is there any chance of bringing
> that back? It was very useful.
Yes, there's some interest in getting the reports working again,
though there are some limitations in DNF (most are related to rich
dependencies) that need to be worked around somehow. Once it works
reliably (and correctly), we can work in integrating it into the
infrastructure somehow (maybe as a checking step after composes).
> The report lists the mscore package, which surprised me, since I just
> built it a few days ago. It says:
>
> - mscore (src):
> o pkgconfig(Qt5WebEngine)
>
> There is no problem installing 'pkgconfig(Qt5WebEngine)' in mock on my
> machine. From the spec file:
>
> %ifarch %{qt5_qtwebengine_arches}
> BuildRequires: pkgconfig(Qt5WebEngine)
> %endif
>
> I suspect the check was run on a machine with an architecture not in
> qt5_qtwebengine_arches. In that case, this is a false positive. Do
> you have some way of telling when a BuildRequires is inside an %ifarch
> or %ifnarch block?
Ah, I see what's happening here. So mscore doesn't have ExcludeArch
set, but some feature (presumably an embedded web view?) is only
available on some architectures? I assume that the srpm is rebuilt
somewhere on an architecture that has this feature, and this srpm is
then copied into the -source repositories for all architectures, even
those where this dependency isn't available. This is not a problem
since this conditional is expanded again at build time, but the srpm
metadata contains it unconditionally (which is what matters for
repository metadata, I guess). Maybe that's even a bug :)
I do have some emulation of querying "ExcludeArch" and "ExclusiveArch"
(because I can't query that from the repos). But there's no way (that
I know of) to check for architecture-dependent BuildRequires, except
maybe parsing .spec files directly (which is something I *really*
don't want to do) or rebuilding the srpm files on the target
architecture (which probably would blow up the time required to
generate the report by some orders of magnitude).
I think this kind of "optional BuildRequires" shouldn't be something
too common in fedora, so I can probaly add this stuff to the whitelist
...
> Thanks for running this report, Fabio.
Sure. I'm glad it already proved useful in one case :)
Fabio
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Question about mass rebuilds
On Mon, 25 Nov 2019, Till Maas wrote: On Mon, Nov 25, 2019 at 10:33:54AM -0500, Steven A. Falco wrote: Yet according to koji, there is no build for fc31: https://koji.fedoraproject.org/koji/packageinfo?packageID=avr-libc I'm not saying that anything is wrong - I'm just curious as to why the package wasn't rebuilt. Any guidance/info would be appreciated. One possible explanation is that creating the SRPM failed in Koji. AFAIR, the rebuild will then not listed on the page you linked. There's not even a mass-rebuild commit for avr-libc, though. Scott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 looking for new maintainers
Hi, On 25-11-2019 10:52, Miro Hrončok wrote: So for anyone interested in this: jwrdegoede: buildnumber-maven-plugin The chain here is: sdljava (*):Buildrequires: jruby jruby: [Build]Requires: buildnumber-maven-plugin *) Which I maintain I've broken this chain by removing the BuildRequires as sdljava does not actually need jruby to build. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Development Tools problems for build from source Krita.
yes ecm problem and cmake new version can you provide more help with this issue? thank you. [mythcat@localhost build]$ cmake -DCMAKE_INSTALL_PREFIX=$HOME/krita-4.2.8-beta1/install $HOME/krita-4.2.8-beta1/build -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPRODUCTSET=ALL -DPACKAGERS_BUILD=ON -DBUILD_TESTING=OFF -DKDE4_BUILD_TESTS=OFF -DWITH_GMIC=ON CMake Error at data/CMakeLists.txt:22 (install): install FILES given no DESTINATION! CMake Error at pics/app/CMakeLists.txt:1 (ecm_install_icons): Unknown CMake command "ecm_install_icons". CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 3.14) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP". This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring incomplete, errors occurred! See also "/home/mythcat/krita-4.2.8-beta1/build/CMakeFiles/CMakeOutput.log". See also "/home/mythcat/krita-4.2.8-beta1/build/CMakeFiles/CMakeError.log". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Question about mass rebuilds
On Mon, Nov 25, 2019 at 10:33:54AM -0500, Steven A. Falco wrote: > Yet according to koji, there is no build for fc31: > https://koji.fedoraproject.org/koji/packageinfo?packageID=avr-libc > > I'm not saying that anything is wrong - I'm just curious as to why the > package wasn't rebuilt. Any guidance/info would be appreciated. One possible explanation is that creating the SRPM failed in Koji. AFAIR, the rebuild will then not listed on the page you linked. Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 looking for new maintainers
On Mon, 2019-11-25 at 19:56 +0100, Hans de Goede wrote: > Hi, > > On 25-11-2019 10:52, Miro Hrončok wrote: > > So for anyone interested in this: > > > jwrdegoede: buildnumber-maven-plugin > > The chain here is: > > sdljava (*): Buildrequires: jruby > jruby:[Build]Requires: buildnumber-maven-plugin > > *) Which I maintain > > I've broken this chain by removing the BuildRequires as > sdljava does not actually need jruby to build. ATM , maybe we should just orphan the leaf packs and not the packages that breaks a chain. I'm thinking in Java stack , I think could be a temporary workaround . Another idea is leave more than 6 weeks the package orphan, maybe 6 months. Best regards, -- 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
Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
== Summary ==
Remove ''nullok'' parameter from pam_unix module in default PAM
configuration in order to disallow authentication with empty password.
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email:
== Detailed Description ==
Current default configuration allows users to login with an empty
password by setting nullok parameter to pam_unix module. This affects
only logins to local machine, it does not affect ssh logins as this
must be explicitly allowed in sshd_config. We want to disallow empty
password by default for local logins as well to improve system
hardening.
Note: It is possible to disallow empty passwords with authselect call
(authselect enable-feature without-nullok) or by removing nullok
manually, however it creates possible issues in other components that
must be addressed.
=== Affected Components ===
* '''passwd''' - calling passwd -d to remove users password must be
denied if empty passwords are disallowed otherwise the user will be
locked out of the system
* '''AccountService''' - D-Bus methods ''SetPassword'' and
''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
remove user’s password and lock the user out of the system if empty
password is disallowed. These calls must be denied in this case.
Additionally, these methods can be run by normal users as opposed to
''passwd -d'' and ''chage -d 0'' which can be run only by root.
Therefore only root should be able to call these methods.
* '''Gnome’s Control Center''' - when creating new users, it provides
an option to “require password to be set on first login” which creates
user with expired empty password. This would again lock the user out
of the system.
* '''Other Desktop Environments''' - may have the same issue as Gnome
Control Center
=== Solution Step by Step ===
Step 1) Provide a unified way to read if nullok is enabled or not
We will create an authselect library call that would parse existing
PAM configuration (not necessarily generated by authselect) and return
list of enabled/disabled features. We will implement only ''nullok''
feature in the scope of this change but if needed it can be extended
in the future.
Step 2) Fix passwd -d
Calling ''passwd -d'' to remove user's password will fail if
''nullok'' is disabled.
Step 3) Fix AccountService
These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
will be callable only by ''root'' and must return an error if
''nullok'' is disabled.
SetPasswordMode
SetPassword(“”, hint)
Step 4) Fix Desktop Environments
“Require password change on next login” must keep working. This
feature currently relies on setting an empty password. A new option
''nullresetok'' will be implemented for ''pam_unix'' module that will
allow user to authenticate with empty password only if a password
change for this user is enforced upon login. Authentication with empty
passwords which are not expired will be prohibited (unless ''nullok''
is set).
Step 5) Update PAM configuration to disable nullok by default
In authselect and pam components for new installations. Upgrading from
older systems will keep nullok present.
== Benefit to Fedora ==
Changes in described components (Step 1 - Step 4) are necessary to
implement in order to make sure that user accounts and tools works
correctly when authentication with empty password is disabled by
system administrator. Changing system default to disallow
authentication with empty passwords (Step 5) improves system
hardening.
== Scope ==
* Proposal owners: Coordinate the work. Make sure all required changes
are implemented.
* Other developers: All affected component must be fixed. Changes are
described in ''Detailed Description''
* Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This does not affect system upgrades because only new installation
will have changed default.
== How To Test ==
* Calling ''passwd -d user'' as root must fail with default configuration.
* Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
default configuration.
* "require password reset on first login" must keep working when
creating users from Desktop Environment's GUI tools
== User Experience ==
Users will no longer be able to use empty passwords by default.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Default behavior will not be changed.
* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No
== Documentation ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list --
Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
This Change has been withdrawn and replaced with https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup Discussion is at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ONEOQ4XWRL7IUNTQA7YFSFTNHXY5MJS4/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning owncloud and nextcloud
Thanks for taking this on, Ivan! However, I do think the package should either be updated to a non-EOL version right now, or orphaned for the time being as to not let users install this ancient version that they'll never be able to update. Unfortunately, I don't have time to chime in myself at the moment, but I did some work on getting version 13 packaged early last year, maybe that's helpful for further work: https://github.com/LorbusChris/nextcloud-rpm Best regards Christian On Thu, Oct 31, 2019 at 2:30 PM Ivan Chavero wrote: > I can take over nextcloud > > On Thu, Oct 31, 2019 at 5:20 AM James Hogarth > wrote: > >> Hi all, >> >> There's been no interest from anyone else so I've gone ahead and orphaned >> these. >> >> James >> >> >> On Mon, 21 Oct 2019 at 10:16, James Hogarth >> wrote: >> >>> Hi all, >>> >>> It's become clear that I haven't had the time I thought I'd have this >>> past year due to $life ... >>> >>> These are in a bit of a broken state and right now I'd advise people >>> that need them to use upstream packages/containers. >>> >>> I don't foresee sufficient time coming in the near future with family >>> needs in advance of hobbies like Fedora of course. >>> >>> I'll give it a week or so for anyone to contact me who wants to pick >>> them up, otherwise I'll update pagure to assign them to "orphan" >>> >>> James >>> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/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: Do we need a "No broken deps" Objective?
On Mon, Nov 25, 2019 at 09:16:26AM -0800, Adam Williamson wrote: > On Mon, 2019-11-25 at 13:13 +0100, Fabio Valentini wrote: > > Hi everybody, > > > > I'm a bit concerned about the growing number of broken dependencies in > > fedora, which leads to non-installable (FTI) and un-buildable (FTBFS) > > packages. For rawhide [0], I see almost 400 source packages and almost > > 200 x86_64 packages with broken deps. Especially the number of source > > packages with broken dependencies has steadily been growing since 29. > > I'd say the main problem here is not a lack of an objective but a lack > of information. Back when the tooling still worked and we got a daily > email with a handy list of packages with broken deps, I and Kevin Fenzi > and others would regularly go through it and fix the ones we could fix, > occasionally we'd get down to zero, but we always kept on top of it to > some extent. Now there isn't a handy list any more, we just don't do > this as much because it's not as easy to find what needs fixing in the > first place. > > The most useful thing to do here would be to fix up the tooling so we > get a reliable daily report again. +1 It's much easier to fix things where there's a handy list of broken things. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, 2019-11-25 at 16:25 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
>
> == Summary ==
> Remove ''nullok'' parameter from pam_unix module in default PAM
> configuration in order to disallow authentication with empty password.
>
> == Owner ==
> * Name: [[User:pbrezina| Pavel Březina]]
> * Email:
>
> == Detailed Description ==
>
> Current default configuration allows users to login with an empty
> password by setting nullok parameter to pam_unix module. This affects
> only logins to local machine, it does not affect ssh logins as this
> must be explicitly allowed in sshd_config. We want to disallow empty
> password by default for local logins as well to improve system
> hardening.
>
> Note: It is possible to disallow empty passwords with authselect call
> (authselect enable-feature without-nullok) or by removing nullok
> manually, however it creates possible issues in other components that
> must be addressed.
>
> === Affected Components ===
> * '''passwd''' - calling passwd -d to remove users password must be
> denied if empty passwords are disallowed otherwise the user will be
> locked out of the system
> * '''AccountService''' - D-Bus methods ''SetPassword'' and
> ''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
> remove user’s password and lock the user out of the system if empty
> password is disallowed. These calls must be denied in this case.
> Additionally, these methods can be run by normal users as opposed to
> ''passwd -d'' and ''chage -d 0'' which can be run only by root.
> Therefore only root should be able to call these methods.
> * '''Gnome’s Control Center''' - when creating new users, it provides
> an option to “require password to be set on first login” which creates
> user with expired empty password. This would again lock the user out
> of the system.
> * '''Other Desktop Environments''' - may have the same issue as Gnome
> Control Center
This would definitely also affect the installation, unless we want to create
user accounts
that can't log in.
So the list of affected components should include also Anaconda and Gnome
Initial Setup.
>
> === Solution Step by Step ===
>
> Step 1) Provide a unified way to read if nullok is enabled or not
>
> We will create an authselect library call that would parse existing
> PAM configuration (not necessarily generated by authselect) and return
> list of enabled/disabled features. We will implement only ''nullok''
> feature in the scope of this change but if needed it can be extended
> in the future.
>
> Step 2) Fix passwd -d
> Calling ''passwd -d'' to remove user's password will fail if
> ''nullok'' is disabled.
>
> Step 3) Fix AccountService
> These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
> will be callable only by ''root'' and must return an error if
> ''nullok'' is disabled.
>
> SetPasswordMode
> SetPassword(“”, hint)
>
> Step 4) Fix Desktop Environments
> “Require password change on next login” must keep working. This
> feature currently relies on setting an empty password. A new option
> ''nullresetok'' will be implemented for ''pam_unix'' module that will
> allow user to authenticate with empty password only if a password
> change for this user is enforced upon login. Authentication with empty
> passwords which are not expired will be prohibited (unless ''nullok''
> is set).
>
> Step 5) Update PAM configuration to disable nullok by default
> In authselect and pam components for new installations. Upgrading from
> older systems will keep nullok present.
>
> == Benefit to Fedora ==
>
> Changes in described components (Step 1 - Step 4) are necessary to
> implement in order to make sure that user accounts and tools works
> correctly when authentication with empty password is disabled by
> system administrator. Changing system default to disallow
> authentication with empty passwords (Step 5) improves system
> hardening.
>
> == Scope ==
> * Proposal owners: Coordinate the work. Make sure all required changes
> are implemented.
> * Other developers: All affected component must be fixed. Changes are
> described in ''Detailed Description''
> * Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
> check of an impact with Release Engineering is needed)
>
>
> * Policies and guidelines: No updates needed.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> This does not affect system upgrades because only new installation
> will have changed default.
>
> == How To Test ==
>
> * Calling ''passwd -d user'' as root must fail with default configuration.
> * Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
> ''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
> default configuration.
> * "require password reset on first login" must keep working when
> creating users from Desktop
Fedora 32 System-Wide Change proposal: The GNU C Library version 2.31
https://fedoraproject.org/wiki/Changes/GLIBC231 == Summary == Switch glibc in Fedora 32 to glibc version 2.31. == Owner == * Name: [[User:submachine|Arjun Shankar]] * Email: ar...@redhat.com == Detailed Description == The GNU C Library version 2.31 will be released at the beginning of February 2020; we have started closely tracking the glibc 2.31 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 32 will branch after the GLIBC 2.31 upstream release. However, the mass rebuild schedule means Fedora 32 will mass rebuild (if required) after GLIBC 2.31 upstream freezes ABI for release, but before the actual release, so careful attention must be paid to any last minute ABI changes. == Benefit to Fedora == Stays up to date with latest security and bug fixes from glibc upstream. == Scope == * Proposal owners: Update glibc to 2.31. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 32 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. * Release engineering: [https://pagure.io/releng/issue/9040 #9040] * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The library is backwards compatible with the version of glibc that was shipped in Fedora 31. Some packaging changes required, see: https://sourceware.org/glibc/wiki/Release/2.31#Packaging_Changes We fully expect to fix all packaging changes in Fedora Rawhide given that glibc in Rawhide is tracking what will become glibc 2.31. == How To Test == The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future may also run the microbenchmark to look for performance regressions. == User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc. The glibc 2.31 NEWS update will include more details. == Dependencies == All packages do not need to be rebuilt. == Contingency Plan == * Contingency mechanism: Given that Rawhide has started tracking glibc 2.31, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.30 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency deadline: Upstream ABI freeze deadline of 2020-01-01. * Blocks release? Yes, upgrading glibc does block the release. We should not ship without a newer glibc, there will be gcc and language features that depend on glibc being upgraded. Thus without the upgrade some features will be disabled or fall back to less optimal implementations. == Documentation == The glibc manual contains the documentation for the release and doesn't need any more additional work. == Release Notes == The GNU C Library version 2.31 will be released at the beginning of February 2020. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 Self-Contained Change proposal: Build Python with -fno-semantic-interposition for better performance
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
Simplified version of another change proposal|This change was
originally proposed for [[Releases/32|Fedora 32]] as
[[Changes/PythonStaticSpeedup]], however based on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NWPVQSKVWDKA75PDEIJNJIFL5C5SJXB2/
community feedback], it has been significantly reduced.
== Summary ==
We add the -fno-semantic-interposition compiler/linker
flag when building Python interpreters, as it provides significant
performance improvement, up to 27% depending on the workload. Users
will no longer be able to use LD_PRELOAD to override a symbol from
libpython, which we consider a good trade off for the speedup.
== Owner ==
* Name: [[User:Cstratak| Charalampos Stratakis]], [[User:Vstinner|
Victor Stinner]], [[User:Churchyard| Miro Hrončok]]
* Email: python-ma...@redhat.com
* Shout-out: [[User:Jankratochvil|Jan Kratochvíl]] for first
suggesting this instead of the original proposal, followed by
[[User:Kkofler|Kevin Kofler]]. [[User:Fweimer|Florian Weimer]] for
providing answers to our questions. David Gray for originally
suggesting to link Python statically to gain performance.
== Detailed Description ==
When we build the Python interpreter with the
-fno-semantic-interposition compiler/linker flag, we can
achieve a performance gain of 5% to 27% depending on the workload.
Link time optimizations and profile guided optimizations also have a
greater impact when python3 is built this way.
As a negative side effect, it disables the LD_PRELOAD feature: it's no
longer possible to override symbols in libpython with LD_PRELOAD.
Interposition is enabled by default in compilers like GCC: function
calls to a library goes through a "Procedure Linkage Table" (PLT).
This indirection is required to allow a library loaded by LD_PRELOAD
environment variable to override a function. The indirection puts more
pressure on the CPU level 1 cache (instruction cache). In term of
performance, the main drawback is that function calls from a library
to the same library cannot be inlined, to respect the interposition
semantics. Inlining is usually a big win in term of performance.
Disabling interposition for libpython removes the overhead on function
calls by avoiding the PLT indirection, and allows to inline more
function calls. We're describing function calls from libpython to
libpython, something which is very common in Python: almost all
function calls are calls from libpython to libpython.
If Fedora users need to use LD_PRELOAD to override symbols in
libpython, the recommend way is to build a custom Python without
-fno-semantic-interposition.
It is still possible to use LD_PRELOAD to override symbols in other
libraries (for example in glibc).
=== Affected Pythons ===
Primarily, we will change the interpreter in the {{package|python3}}
package, that is Python 3.8 in Fedora 32 and any later version of
Python in future Fedora releases.
Impact on other Python packages (and generally software using Python)
is not anticipated (other than the possible speedup).
We will also change the
[https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html
alternate Python interpreters] where possible and useful, primarily
the upstream supported versions of CPython, such as
{{package|python39}} (if already packaged), {{package|python37}} and
{{package|python36}}.
=== Affected Fedora releases ===
This is a Fedora 32 change and it will be implemented in Rawhide
(Fedora 32) only. Any future versions of Fedora will inherit the
change until it is reverted for some reason.
If it turns out that there are absolutely no issues, we might consider
backporting the speedup to already released Fedora versions (for
example Fedora 31). Such action would be separately coordinated with
[https://docs.fedoraproject.org/en-US/fesco/ FESCo].
== Benefit to Fedora ==
Python's performance will increase significantly depending on the
workload. Since many core components of the OS also depend on Python
this could lead to an increase in their performance as well, however
individual benchmarks will need to be conducted to verify the
performance gain for those components.
[https://pyperformance.readthedocs.io/ pyperformance] results,
ignoring differences smaller than 5%:
(See change proposal)
== Scope ==
* Proposal owners:
** Review and merge the
[https://src.fedoraproject.org/rpms/python3/pull-request/151 pull
request with the implementation].
** Monitor Koschei for significant problems.
** Backport the change to alternate Python versions.
* Other developers are encouraged to check if their package works as expected
* Release engineering: N/A (not needed for this Change) -- this change
does not require a mass rebuild nor any other special releng work
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Python
Fedora 32 Self-Contained Change proposal: Rebase apt package from apt-rpm to Debian's apt
https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_backend == Summary == Currently the apt package in Fedora actually installs apt-rpm, starting with Fedora 32 it will provide the regular apt software backed by DPKG. == Owner == * Name: [[User:dridi| Dridi Boukelmoune]], [[User:ngompa | Neal Gompa]] * Email: dr...@fedoraproject.org, ngomp...@gmail.com == Detailed Description == The apt package in Fedora does not ship the mainline apt software from Debian, but rather the apt-rpm fork instead. This allows a user to copy and paste apt or apt-get commands often found in "Linux" tutorials. This will usually work, apt-rpm will resolve dependencies from the Yum/DNF repositories and since our package naming guidelines often lead to the same package names as apt-based distributions like Debian and Ubuntu. The apt-rpm software is dead upstream and doesn't support rich dependencies or modules. It also has known vulnerabilities and according to its author other bugs that are never going to be fixed. == Benefit to Fedora == By switching the Fedora apt package from apt-rpm to regular apt we move from a dead to a living upstream. We also close security holes and introduce a critical dependency for more packages from the DPKG ecosystem. It is already possible to build Deb packages in Fedora, including with pbuilder, an equivalent for mock in the DPKG ecosystem, however pbuilder uses debootstrap to provision a build environment. While we may lose the ability to "apt-get install" Fedora packages from the command line, we also open the gate for sbuild, another mock equivalent to build Debs in a clean environment. This change offers more options to target Debian and derivative systems without leaving the Fedora comfort zone. == Scope == * Proposal owners: re-review of the apt package with the proper upstream ([https://bugzilla.redhat.com/show_bug.cgi?id=1764813 RH#1764813]), and optionally more dependent packages. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: As apt would conflict with DNF for the host system, we may want to ship it without pre-configured repositories. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Any user actively relying on apt-rpm will lose functionality that cannot be replaced. Because apt-rpm's version is much lower than the current apt version, this change will follow the natural upgrade path. == How To Test == If sbuild is packaged in time for the beta, performing builds with sbuild should be enough to confirm that apt was able to provision a build root. == User Experience == Anyone used to paste apt-get commands in a terminal will no longer be able to install or remove Fedora packages this way. On the other hand anyone needing regular apt tooling will be able to work with it directly from Fedora. == Dependencies == Apt shouldn't bring more dependencies, it will be the dependency for more packages from the DPKG ecosystem. == Contingency Plan == * Contingency mechanism: Simply retire apt (apt-rpm) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A == Documentation == Once installed, apt ships multiple manual pages available in several languages. There will no longer be any references in the shipped apt package documentation of handling RPMs. == Release Notes == The apt package has been rebased from apt-rpm to Debian's apt. This means that apt no longer supports handling RPMs or managing RPM-based systems. Please use dnf for software management of RPM-based systems and containers. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On 11/25/19 1:25 PM, Ben Cotton wrote: == Benefit to Fedora == Changes in described components (Step 1 - Step 4) are necessary to implement in order to make sure that user accounts and tools works correctly when authentication with empty password is disabled by system administrator. Changing system default to disallow authentication with empty passwords (Step 5) improves system hardening. Steps 1 - 4 are not benefits, they are workarounds to critical system utilities required by this change. I don't understand why this change is necessary at all. It only affects local logins and if someone wants to have an empty password, why make it so difficult? It's their choice. It's not like Fedora has any default logins with empty passwords, the user has to make their own. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Atomic Host Nearing End Of Life
On 11/25/19 11:41 AM, Normand wrote: > > > On 11/21/19 11:33 PM, Dusty Mabe wrote: >> This content also exists at: >> https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/ >> >> Last year we [introduced the plans for Fedora CoreOS] [1] including that >> Fedora CoreOS would be the successor to Fedora Atomic Host and Container >> Linux (from CoreOS Inc.). As part of that succession plan we decided that >> Fedora 29 Atomic Host would be the last stream of Fedora Atomic Host to be >> released. >> >> Fedora 29 Atomic Host has served us well, but with Fedora 29 End of >> Life coming soon [2], so will the last release of Fedora 29 Atomic Host. >> The next release of Fedora 29 Atomic Host (in the next few weeks) will be >> the last two-week release. It will contain all of the latest content >> from Fedora 29. After that release, Fedora 29, and Fedora 29 Atomic >> Host will no longer receive any updates. >> >> Please try out the Fedora CoreOS preview to help us get it towards >> stable. Documentation and download links can be found at >> https://getfedora.org/coreos/ >> >> The Atomic Host Team >> >> [1] https://fedoramagazine.org/announcing-fedora-coreos/ >> [2] >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUK3CJ5LO4ROUH3JTCDVHYAVVYAOCU62/ >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > > > Thanks for the info, > > But what about arches that are not x86_64 ? > Where could we found for exemple the ppc64le coreos replacement of > Atomic Host ? Is there already a web page to retrieve them ? > Hi Normand, Thank you for bringing this up. You have indeed pointed out a gap in what we're currently delivering with Fedora CoreOS preview and what we were delivering with Atomic Host. The good news is that we have done enablement work to allow for Fedora CoreOS to be run on other platforms. The bad news is that we don't currently run our build infrastructure in an environment that has other architectures available. So while you can build it yourself today, there is currently no where to download it from the Fedora website. I have added Jakub Cajka who was working on getting some space to host unofficial builds of Fedora CoreOS for other architectures for now. I'll also link you to our open issues where we're working through our strategy for delivering multi-arch FCOS: - https://github.com/coreos/fedora-coreos-tracker/issues/262 - https://pagure.io/fedora-infrastructure/issue/8370 - Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Monday, November 25, 2019 2:59:18 PM MST Samuel Sieb wrote: > On 11/25/19 1:25 PM, Ben Cotton wrote: > > > == Benefit to Fedora == > > > > Changes in described components (Step 1 - Step 4) are necessary to > > implement in order to make sure that user accounts and tools works > > correctly when authentication with empty password is disabled by > > system administrator. Changing system default to disallow > > authentication with empty passwords (Step 5) improves system > > hardening. > > > Steps 1 - 4 are not benefits, they are workarounds to critical system > utilities required by this change. I don't understand why this change > is necessary at all. It only affects local logins and if someone wants > to have an empty password, why make it so difficult? It's their choice. > It's not like Fedora has any default logins with empty passwords, the > user has to make their own. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org I would have to agree. It's one thing to warn non-technical users when setting empty passwords, another entirely to prevent them. Many non-technical users just don't want a password set on their system. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity Team (weekly)
Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2019-11-26 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9480/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Hi, Lily Nie from Fedora QE team here,and I'm working with local virt-QE on putting their automation tools to Fedora repo. I have filed a review request for avocado-vt : https://bugzilla.redhat.com/show_bug.cgi?id=1773467 I haven't maintained any packages before,but I have sent some merged pull requests to python based projects. I'm trying my best to become a Fedora package maintainer, and I also have contacted the upstream maintainer and he feels glad to help me on maintaining the package if needed. Sincerely hope you can spare some time on reviewing my pull request,thanks. Best Regards and thanks, Lily ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Disallow Empty Password By Default
Samuel Sieb wrote: > Steps 1 - 4 are not benefits, they are workarounds to critical system > utilities required by this change. I don't understand why this change > is necessary at all. It only affects local logins and if someone wants > to have an empty password, why make it so difficult? It's their choice. +1, I do not see the point of patronizing our users that way (and it is only an extra hoop to jump through because they can still readd the nullok), and find it particularly pointless to make all those error-prone changes to core system utilities just to make that work. > It's not like Fedora has any default logins with empty passwords, the > user has to make their own. That part is actually not entirely true: the live images have no password set on the liveuser and root accounts. Hence, this change will also break the live images, unless we add yet another hack to the scriptlets in the live kickstarts, one that readds the nullok option. IMHO, we already have too many hacks in the kickstart scriptlets. 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, 2019-11-26 at 00:34 +0100, Kevin Kofler wrote: > Samuel Sieb wrote: > > Steps 1 - 4 are not benefits, they are workarounds to critical system > > utilities required by this change. I don't understand why this change > > is necessary at all. It only affects local logins and if someone wants > > to have an empty password, why make it so difficult? It's their choice. > > +1, I do not see the point of patronizing our users that way (and it is only > an extra hoop to jump through because they can still readd the nullok), and > find it particularly pointless to make all those error-prone changes to core > system utilities just to make that work. > > > It's not like Fedora has any default logins with empty passwords, the > > user has to make their own. > > That part is actually not entirely true: the live images have no password > set on the liveuser and root accounts. Hence, this change will also break > the live images, unless we add yet another hack to the scriptlets in the > live kickstarts, one that readds the nullok option. IMHO, we already have > too many hacks in the kickstart scriptlets. I gotta say +1 too. I don't buy that there's a significant 'hardening' benefit worth all the effort mentioned in the Change *plus* the additional consequences Kevin and Martin pointed out. At minimum I'd like to see a much more convincing case that people are creating users without passwords without understanding what they're doing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Hi, Setting aside the question of how anaconda, gnome-initial-setup, and the liveuser sessions would work, I have a question about the complaint regarding accountsservice. On Mon, Nov 25, 2019 at 4:25 pm, Ben Cotton wrote: * '''AccountService''' - D-Bus methods ''SetPassword'' and ''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can remove user’s password and lock the user out of the system if empty password is disallowed. These calls must be denied in this case. OK, makes sense. But: Additionally, these methods can be run by normal users as opposed to ''passwd -d'' and ''chage -d 0'' which can be run only by root. Therefore only root should be able to call these methods. So... then users can't change their own passwords? We don't enable root account in Workstation anyway, it would become impossible to ever change any password via accountsservice. Let's assume you meant "only admin users should be able to call these methods" instead of "only root". Even then, I still don't understand the problem. I just tested using D-Feet to manually change my password using org.freedesktop.Accounts SetPassword, and it required that I authenticate via polkit. polkit is good; let it do its thing. It's checking the org.freedesktop.accounts.change-own-password action, which requires auth_admin authentication. So what is the problem here? Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1776472] perl-Devel-PPPort-3.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1776472 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com,| |ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1776575] perl-Text-Xslate-3.5.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1776575 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1775789] perl-Fsdb for epel8
https://bugzilla.redhat.com/show_bug.cgi?id=1775789 John Heidemann changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed||2019-11-26 06:58:10 --- Comment #8 from John Heidemann --- Yes, thank you very much. Epel8 should now be active. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1775789] perl-Fsdb for epel8
https://bugzilla.redhat.com/show_bug.cgi?id=1775789 --- Comment #9 from John Heidemann --- Yes, thank you very much. Epel8 should now be active. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] Re: Recent epel 8 branchs - no tag of package in epel
Am 26.11.19 um 02:07 schrieb Sérgio Basto: > Seems we need to wait an amount of time to koji get synced with > request, but how long we have to wait ? Someone on IRC told me https://pagure.io/releng/issue/9041 is related to these symptoms. Felix ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[Bug 1776106] Upgrade perl-MCE to 1.863
https://bugzilla.redhat.com/show_bug.cgi?id=1776106 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |DUPLICATE Last Closed||2019-11-25 08:27:32 --- Comment #1 from Paul Howarth --- *** This bug has been marked as a duplicate of bug 1776105 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1776105] perl-MCE-1.863 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1776105 Paul Howarth changed: What|Removed |Added CC||jples...@redhat.com --- Comment #1 from Paul Howarth --- *** Bug 1776106 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1775830] perl-Archive-Extract-0.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1775830 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Archive-Extract-0.82-1 ||.fc32 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1775830] perl-Archive-Extract-0.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1775830 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-11-26 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/11/26/report-389-ds-base-1.4.2.4-20191126gitf439447.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via releng issues: https://pagure.io/releng/issues Full report available at: https://churchyard.fedorapeople.org/orphans-2019-11-25.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change ExchangeIRorphan 1 weeks ago FUR orphan 2 weeks ago airsnort orphan 2 weeks ago apache-logging-parent mizdebsk, orphan 1 weeks ago apache-mime4j orphan 4 weeks ago apt-cacher-ng orphan 1 weeks ago archaius orphan 1 weeks ago archmage lbazan, orphan 0 weeks ago audit-viewer mitr, orphan 0 weeks ago avalon-logkit jerboaa, mizdebsk, orphan0 weeks ago base64coder jcapik, mizdebsk, orphan 2 weeks ago batik jvanek, mizdebsk, orphan 2 weeks ago buildnumber-maven-plugin orphan 0 weeks ago bval orphan 1 weeks ago camotics orphan 1 weeks ago cduce orphan 1 weeks ago clapham orphan 1 weeks ago classmate lef, orphan 3 weeks ago cli-parserlef, orphan 3 weeks ago csstidy orphan 1 weeks ago delve go-sig, orphan 1 weeks ago dillo aarem, orphan2 weeks ago eclipse-anyedit eclipse-sig, orphan, swagiaal1 weeks ago eclipse-avr orphan 1 weeks ago eclipse-cdt akurtakov, eclipse-sig, 4 weeks ago jjohnstn, kdaniel, orphan, rgrunber eclipse-checkstyleakurtakov, eclipse-sig, orphan 1 weeks ago eclipse-color-theme eclipse-sig, orphan 1 weeks ago eclipse-dltk akurtakov, eclipse-sig, 1 weeks ago kdaniel, orphan, rgrunber eclipse-egit akurtakov, arobinso, eclipse-1 weeks ago sig, jerboaa, jjohnstn, kdaniel, nguzman, orphan, rgrunber eclipse-emf akurtakov, eclipse-sig, 1 weeks ago jjohnstn, kdaniel, orphan, rgrunber eclipse-epic eclipse-sig, orphan 1 weeks ago eclipse-gef akurtakov, eclipse-sig, 1 weeks ago kdaniel, orphan, rgrunber eclipse-launchbar eclipse-sig, orphan, sopotc 3 weeks ago eclipse-license eclipse-sig, orphan 1 weeks ago eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-apt eclipse-sig, orphan 1 weeks ago eclipse-m2e-buildhelper eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-core eclipse-sig, galileo,1 weeks ago mizdebsk, orphan eclipse-m2e-cxf eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-egit eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-maven-dependency- mizdebsk, orphan 1 weeks ago plugin eclipse-m2e-mavenarchiver eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-mavendev eclipse-sig, mizdebsk, orphan1 weeks ago eclipse-m2e-modello eclipse-sig, mizdebsk, orphan1 weeks
[Bug 1776105] perl-MCE-1.863 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1776105 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-MCE-1.863-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2019-11-25 15:19:22 --- Comment #2 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=39325852 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1775830] perl-Archive-Extract-0.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1775830 --- Comment #4 from Fedora Update System --- FEDORA-2019-c79b8e9fd1 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c79b8e9fd1 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1775830] perl-Archive-Extract-0.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1775830 --- Comment #2 from Fedora Update System --- FEDORA-2019-bab77ca5b8 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bab77ca5b8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1776110] Upgrade perl-Specio to 0.45
https://bugzilla.redhat.com/show_bug.cgi?id=1776110 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Paul Howarth --- This is going to require the currently unpackaged perl(XString). I'll look at packaging it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1775830] perl-Archive-Extract-0.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1775830 --- Comment #3 from Fedora Update System --- FEDORA-2019-276a49f5b1 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-276a49f5b1 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1776472] New: perl-Devel-PPPort-3.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1776472 Bug ID: 1776472 Summary: perl-Devel-PPPort-3.56 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-PPPort Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.56 Current version/release in rawhide: 3.55-1.fc32 URL: http://search.cpan.org/dist/Devel-PPPort/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5760/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1776110] Upgrade perl-Specio to 0.45
https://bugzilla.redhat.com/show_bug.cgi?id=1776110 Paul Howarth changed: What|Removed |Added Depends On||1776513 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1776513 [Bug 1776513] Review Request: perl-XString - Isolated String helpers from B -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
pghmcfc pushed to perl-MCE-Shared (master). "Update to 1.863 (..more)"
Notification time stamped 2019-11-25 18:43:37 UTC
From 64f92bb61096fae7379ee500016f4983aceba6ca Mon Sep 17 00:00:00 2001
From: Paul Howarth
Date: Nov 25 2019 18:42:50 +
Subject: Update to 1.863
- New upstream release 1.863
- Use MCE::Channel for MCE::Hobo->yield not to incur unnecessary delays due
to busy shared-manager process
- Re-factored recent changes regarding IPC safety in MCE::Shared::Server;
this update defers signal handling for HUP, INT, PIPE, QUIT, TERM, and
custom handlers during IPC without incurring a performance penalty (see
POD section labled "DEFER SIGNAL" in MCE::Signal 1.863)
- Reverted $hobo->exit back to sending the SIGQUIT signal in MCE::Hobo now
that MCE::Shared::Server defers signal during IPC
- Improved reliability for spawning MCE::Hobo inside threads including nested
parallelization, made possible using a global lock $MCE::_GMUTEX in MCE
1.863
- Updated signal handling in mce-examples/framebuffer on GitHub
- Bumped MCE dependency to 1.863
---
diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index a22d96d..f8905c0 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,5 +1,5 @@
Name: perl-MCE-Shared
-Version: 1.862
+Version: 1.863
Release: 1%{?dist}
Summary: MCE extension for sharing data, supporting threads and processes
License: GPL+ or Artistic
@@ -20,7 +20,7 @@ BuildRequires:perl(Carp)
BuildRequires: perl(constant)
BuildRequires: perl(Errno)
BuildRequires: perl(if)
-BuildRequires: perl(MCE) >= 1.862
+BuildRequires: perl(MCE) >= 1.863
BuildRequires: perl(MCE::Mutex)
BuildRequires: perl(MCE::Signal)
BuildRequires: perl(MCE::Util)
@@ -43,7 +43,7 @@ BuildRequires:perl(Test::More) >= 0.88
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
Requires: perl(IO::FDPass) >= 1.2
-Requires: perl(MCE) >= 1.862
+Requires: perl(MCE) >= 1.863
Requires: perl(overloading)
Requires: perl(POSIX)
Requires: perl(Storable) >= 2.04
@@ -92,6 +92,22 @@ make test
%{_mandir}/man3/MCE::Shared::Server.3*
%changelog
+* Mon Nov 25 2019 Paul Howarth - 1.863-1
+- Update to 1.863
+ - Use MCE::Channel for MCE::Hobo->yield not to incur unnecessary delays due
+to busy shared-manager process
+ - Re-factored recent changes regarding IPC safety in MCE::Shared::Server;
+this update defers signal handling for HUP, INT, PIPE, QUIT, TERM, and
+custom handlers during IPC without incurring a performance penalty (see
+POD section labled "DEFER SIGNAL" in MCE::Signal 1.863)
+ - Reverted $hobo->exit back to sending the SIGQUIT signal in MCE::Hobo now
+that MCE::Shared::Server defers signal during IPC
+ - Improved reliability for spawning MCE::Hobo inside threads including nested
+parallelization, made possible using a global lock $MCE::_GMUTEX in MCE
+1.863
+ - Updated signal handling in mce-examples/framebuffer on GitHub
+ - Bumped MCE dependency to 1.863
+
* Thu Sep 19 2019 Paul Howarth - 1.862-1
- Update to 1.862
- The edge cases regarding signal handling have finally been resolved for
diff --git a/sources b/sources
index 6c137bc..0f3cffe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.862.tar.gz) =
7614d94999213fca217a7f2f4081639108c7a3b60c8bf419622f380b934da55a4ec6b8b69350ac99a1a2caa0879502fbd35e065308f88cba6ec55d4651b7badb
+SHA512 (MCE-Shared-1.863.tar.gz) =
caf075e1c3db5f49173ae99bbece73e32eff0d0aa53e5cd2579d17e957e6eb0c9a69f89a1365c93e67fefbcfeca69cfc9aba0b508c282db8ff6573ad728d62a5
https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/64f92bb61096fae7379ee500016f4983aceba6ca?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1776107] Upgrade perl-MCE-Shared to 1.863
https://bugzilla.redhat.com/show_bug.cgi?id=1776107 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-MCE-Shared-1.863-1.fc3 ||2 Resolution|--- |RAWHIDE Last Closed||2019-11-25 19:20:23 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=3902 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora 32 Self-Contained Change proposal: Rebase apt package from apt-rpm to Debian's apt
https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_backend == Summary == Currently the apt package in Fedora actually installs apt-rpm, starting with Fedora 32 it will provide the regular apt software backed by DPKG. == Owner == * Name: [[User:dridi| Dridi Boukelmoune]], [[User:ngompa | Neal Gompa]] * Email: dr...@fedoraproject.org, ngomp...@gmail.com == Detailed Description == The apt package in Fedora does not ship the mainline apt software from Debian, but rather the apt-rpm fork instead. This allows a user to copy and paste apt or apt-get commands often found in "Linux" tutorials. This will usually work, apt-rpm will resolve dependencies from the Yum/DNF repositories and since our package naming guidelines often lead to the same package names as apt-based distributions like Debian and Ubuntu. The apt-rpm software is dead upstream and doesn't support rich dependencies or modules. It also has known vulnerabilities and according to its author other bugs that are never going to be fixed. == Benefit to Fedora == By switching the Fedora apt package from apt-rpm to regular apt we move from a dead to a living upstream. We also close security holes and introduce a critical dependency for more packages from the DPKG ecosystem. It is already possible to build Deb packages in Fedora, including with pbuilder, an equivalent for mock in the DPKG ecosystem, however pbuilder uses debootstrap to provision a build environment. While we may lose the ability to "apt-get install" Fedora packages from the command line, we also open the gate for sbuild, another mock equivalent to build Debs in a clean environment. This change offers more options to target Debian and derivative systems without leaving the Fedora comfort zone. == Scope == * Proposal owners: re-review of the apt package with the proper upstream ([https://bugzilla.redhat.com/show_bug.cgi?id=1764813 RH#1764813]), and optionally more dependent packages. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: As apt would conflict with DNF for the host system, we may want to ship it without pre-configured repositories. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Any user actively relying on apt-rpm will lose functionality that cannot be replaced. Because apt-rpm's version is much lower than the current apt version, this change will follow the natural upgrade path. == How To Test == If sbuild is packaged in time for the beta, performing builds with sbuild should be enough to confirm that apt was able to provision a build root. == User Experience == Anyone used to paste apt-get commands in a terminal will no longer be able to install or remove Fedora packages this way. On the other hand anyone needing regular apt tooling will be able to work with it directly from Fedora. == Dependencies == Apt shouldn't bring more dependencies, it will be the dependency for more packages from the DPKG ecosystem. == Contingency Plan == * Contingency mechanism: Simply retire apt (apt-rpm) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A == Documentation == Once installed, apt ships multiple manual pages available in several languages. There will no longer be any references in the shipped apt package documentation of handling RPMs. == Release Notes == The apt package has been rebased from apt-rpm to Debian's apt. This means that apt no longer supports handling RPMs or managing RPM-based systems. Please use dnf for software management of RPM-based systems and containers. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 32 Self-Contained Change proposal: Build Python with -fno-semantic-interposition for better performance
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
Simplified version of another change proposal|This change was
originally proposed for [[Releases/32|Fedora 32]] as
[[Changes/PythonStaticSpeedup]], however based on
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/NWPVQSKVWDKA75PDEIJNJIFL5C5SJXB2/
community feedback], it has been significantly reduced.
== Summary ==
We add the -fno-semantic-interposition compiler/linker
flag when building Python interpreters, as it provides significant
performance improvement, up to 27% depending on the workload. Users
will no longer be able to use LD_PRELOAD to override a symbol from
libpython, which we consider a good trade off for the speedup.
== Owner ==
* Name: [[User:Cstratak| Charalampos Stratakis]], [[User:Vstinner|
Victor Stinner]], [[User:Churchyard| Miro Hrončok]]
* Email: python-ma...@redhat.com
* Shout-out: [[User:Jankratochvil|Jan Kratochvíl]] for first
suggesting this instead of the original proposal, followed by
[[User:Kkofler|Kevin Kofler]]. [[User:Fweimer|Florian Weimer]] for
providing answers to our questions. David Gray for originally
suggesting to link Python statically to gain performance.
== Detailed Description ==
When we build the Python interpreter with the
-fno-semantic-interposition compiler/linker flag, we can
achieve a performance gain of 5% to 27% depending on the workload.
Link time optimizations and profile guided optimizations also have a
greater impact when python3 is built this way.
As a negative side effect, it disables the LD_PRELOAD feature: it's no
longer possible to override symbols in libpython with LD_PRELOAD.
Interposition is enabled by default in compilers like GCC: function
calls to a library goes through a "Procedure Linkage Table" (PLT).
This indirection is required to allow a library loaded by LD_PRELOAD
environment variable to override a function. The indirection puts more
pressure on the CPU level 1 cache (instruction cache). In term of
performance, the main drawback is that function calls from a library
to the same library cannot be inlined, to respect the interposition
semantics. Inlining is usually a big win in term of performance.
Disabling interposition for libpython removes the overhead on function
calls by avoiding the PLT indirection, and allows to inline more
function calls. We're describing function calls from libpython to
libpython, something which is very common in Python: almost all
function calls are calls from libpython to libpython.
If Fedora users need to use LD_PRELOAD to override symbols in
libpython, the recommend way is to build a custom Python without
-fno-semantic-interposition.
It is still possible to use LD_PRELOAD to override symbols in other
libraries (for example in glibc).
=== Affected Pythons ===
Primarily, we will change the interpreter in the {{package|python3}}
package, that is Python 3.8 in Fedora 32 and any later version of
Python in future Fedora releases.
Impact on other Python packages (and generally software using Python)
is not anticipated (other than the possible speedup).
We will also change the
[https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html
alternate Python interpreters] where possible and useful, primarily
the upstream supported versions of CPython, such as
{{package|python39}} (if already packaged), {{package|python37}} and
{{package|python36}}.
=== Affected Fedora releases ===
This is a Fedora 32 change and it will be implemented in Rawhide
(Fedora 32) only. Any future versions of Fedora will inherit the
change until it is reverted for some reason.
If it turns out that there are absolutely no issues, we might consider
backporting the speedup to already released Fedora versions (for
example Fedora 31). Such action would be separately coordinated with
[https://docs.fedoraproject.org/en-US/fesco/ FESCo].
== Benefit to Fedora ==
Python's performance will increase significantly depending on the
workload. Since many core components of the OS also depend on Python
this could lead to an increase in their performance as well, however
individual benchmarks will need to be conducted to verify the
performance gain for those components.
[https://pyperformance.readthedocs.io/ pyperformance] results,
ignoring differences smaller than 5%:
(See change proposal)
== Scope ==
* Proposal owners:
** Review and merge the
[https://src.fedoraproject.org/rpms/python3/pull-request/151 pull
request with the implementation].
** Monitor Koschei for significant problems.
** Backport the change to alternate Python versions.
* Other developers are encouraged to check if their package works as expected
* Release engineering: N/A (not needed for this Change) -- this change
does not require a mass rebuild nor any other special releng work
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Python
Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
== Summary ==
Remove ''nullok'' parameter from pam_unix module in default PAM
configuration in order to disallow authentication with empty password.
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email:
== Detailed Description ==
Current default configuration allows users to login with an empty
password by setting nullok parameter to pam_unix module. This affects
only logins to local machine, it does not affect ssh logins as this
must be explicitly allowed in sshd_config. We want to disallow empty
password by default for local logins as well to improve system
hardening.
Note: It is possible to disallow empty passwords with authselect call
(authselect enable-feature without-nullok) or by removing nullok
manually, however it creates possible issues in other components that
must be addressed.
=== Affected Components ===
* '''passwd''' - calling passwd -d to remove users password must be
denied if empty passwords are disallowed otherwise the user will be
locked out of the system
* '''AccountService''' - D-Bus methods ''SetPassword'' and
''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
remove user’s password and lock the user out of the system if empty
password is disallowed. These calls must be denied in this case.
Additionally, these methods can be run by normal users as opposed to
''passwd -d'' and ''chage -d 0'' which can be run only by root.
Therefore only root should be able to call these methods.
* '''Gnome’s Control Center''' - when creating new users, it provides
an option to “require password to be set on first login” which creates
user with expired empty password. This would again lock the user out
of the system.
* '''Other Desktop Environments''' - may have the same issue as Gnome
Control Center
=== Solution Step by Step ===
Step 1) Provide a unified way to read if nullok is enabled or not
We will create an authselect library call that would parse existing
PAM configuration (not necessarily generated by authselect) and return
list of enabled/disabled features. We will implement only ''nullok''
feature in the scope of this change but if needed it can be extended
in the future.
Step 2) Fix passwd -d
Calling ''passwd -d'' to remove user's password will fail if
''nullok'' is disabled.
Step 3) Fix AccountService
These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
will be callable only by ''root'' and must return an error if
''nullok'' is disabled.
SetPasswordMode
SetPassword(“”, hint)
Step 4) Fix Desktop Environments
“Require password change on next login” must keep working. This
feature currently relies on setting an empty password. A new option
''nullresetok'' will be implemented for ''pam_unix'' module that will
allow user to authenticate with empty password only if a password
change for this user is enforced upon login. Authentication with empty
passwords which are not expired will be prohibited (unless ''nullok''
is set).
Step 5) Update PAM configuration to disable nullok by default
In authselect and pam components for new installations. Upgrading from
older systems will keep nullok present.
== Benefit to Fedora ==
Changes in described components (Step 1 - Step 4) are necessary to
implement in order to make sure that user accounts and tools works
correctly when authentication with empty password is disabled by
system administrator. Changing system default to disallow
authentication with empty passwords (Step 5) improves system
hardening.
== Scope ==
* Proposal owners: Coordinate the work. Make sure all required changes
are implemented.
* Other developers: All affected component must be fixed. Changes are
described in ''Detailed Description''
* Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This does not affect system upgrades because only new installation
will have changed default.
== How To Test ==
* Calling ''passwd -d user'' as root must fail with default configuration.
* Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
default configuration.
* "require password reset on first login" must keep working when
creating users from Desktop Environment's GUI tools
== User Experience ==
Users will no longer be able to use empty passwords by default.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Default behavior will not be changed.
* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No
== Documentation ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list
[Bug 1759801] please build perl-gtk3 for epel 8
https://bugzilla.redhat.com/show_bug.cgi?id=1759801 li...@uw.edu changed: What|Removed |Added CC||li...@uw.edu --- Comment #2 from li...@uw.edu --- I need this for an in-house tool used by our users. This is blocking us from upgrading to 8. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] usbauth package suite for EPEL8
Hi I have successfully built my packages of the usbauth package suite for rawhide, f31 and epel8 branches. Currently, the packages are only part of the rawhide repo. How to get these packages copied to the epel8 and of course f31 repo? libusbauth-configparser: https://koji.fedoraproject.org/koji/packageinfo?packageID=30003 usbauth: https://koji.fedoraproject.org/koji/packageinfo?packageID=30004 usbauth-notifier: https://koji.fedoraproject.org/koji/packageinfo?packageID=30005 Thank you. Best regards Stefan Koch ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: The GNU C Library version 2.31
https://fedoraproject.org/wiki/Changes/GLIBC231 == Summary == Switch glibc in Fedora 32 to glibc version 2.31. == Owner == * Name: [[User:submachine|Arjun Shankar]] * Email: ar...@redhat.com == Detailed Description == The GNU C Library version 2.31 will be released at the beginning of February 2020; we have started closely tracking the glibc 2.31 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 32 will branch after the GLIBC 2.31 upstream release. However, the mass rebuild schedule means Fedora 32 will mass rebuild (if required) after GLIBC 2.31 upstream freezes ABI for release, but before the actual release, so careful attention must be paid to any last minute ABI changes. == Benefit to Fedora == Stays up to date with latest security and bug fixes from glibc upstream. == Scope == * Proposal owners: Update glibc to 2.31. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 32 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. * Release engineering: [https://pagure.io/releng/issue/9040 #9040] * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The library is backwards compatible with the version of glibc that was shipped in Fedora 31. Some packaging changes required, see: https://sourceware.org/glibc/wiki/Release/2.31#Packaging_Changes We fully expect to fix all packaging changes in Fedora Rawhide given that glibc in Rawhide is tracking what will become glibc 2.31. == How To Test == The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future may also run the microbenchmark to look for performance regressions. == User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc. The glibc 2.31 NEWS update will include more details. == Dependencies == All packages do not need to be rebuilt. == Contingency Plan == * Contingency mechanism: Given that Rawhide has started tracking glibc 2.31, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.30 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency deadline: Upstream ABI freeze deadline of 2020-01-01. * Blocks release? Yes, upgrading glibc does block the release. We should not ship without a newer glibc, there will be gcc and language features that depend on glibc being upgraded. Thus without the upgrade some features will be disabled or fall back to less optimal implementations. == Documentation == The glibc manual contains the documentation for the release and doesn't need any more additional work. == Release Notes == The GNU C Library version 2.31 will be released at the beginning of February 2020. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
[Bug 1776561] New: perl-IO-Async-0.75 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1776561 Bug ID: 1776561 Summary: perl-IO-Async-0.75 is available Product: Fedora Version: rawhide Status: NEW Component: perl-IO-Async Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, kwiz...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.75 Current version/release in rawhide: 0.74-2.fc31 URL: http://search.cpan.org/dist/IO-Async Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7999/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1776575] New: perl-Text-Xslate-3.5.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1776575 Bug ID: 1776575 Summary: perl-Text-Xslate-3.5.7 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Text-Xslate Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: i...@cicku.me, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 3.5.7 Current version/release in rawhide: 3.5.6-7.fc31 URL: http://search.cpan.org/dist/Text-Xslate/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3455/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] Re: Recent epel 8 branchs - no tag of package in epel
On Fri, 2019-11-15 at 22:31 +, Sérgio Basto wrote: > On Thu, 2019-11-14 at 18:33 +, Paul Howarth wrote: > > On Thu, 14 Nov 2019 15:08:32 +0100 > > Steve Traylen wrote: > > > > > Hi, > > > > > > > > > Last couple of days the epel8 branch requests have been processed > > > okay. Thanks > > > > > > However when you then try and build something it results in > > > > > > BuildError: package X not in list for tag epel8-playground- > > > pending > > > > > > > > > Example: > > > > > > > > > https://pagure.io/releng/fedora-scm-requests/issue/19622 > > > https://pagure.io/releng/fedora-scm-requests/issue/19623 > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=38994106 > > > > > > has occurred for multiple recently branched packages. I think > > > earlier > > > in the week all was good. > > > > It seems to be fixed now. So far so good anyway. > > I got the same error in these 2 cases [1] , I requested the branches > today > > [1] > https://koji.fedoraproject.org/koji/taskinfo?taskID=39019804 > https://koji.fedoraproject.org/koji/taskinfo?taskID=39019796 Seems we need to wait an amount of time to koji get synced with request, but how long we have to wait ? Today I got one error in epel8 [1] and one in epel8-playground [2] [1] BuildError: package pbuilder not in list for tag epel8-testing- candidate [2] BuildError: package pbuilder not in list for tag epel8-playground- pending -- Sérgio M. B. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: usbauth package suite for EPEL8
On 11/25/19 3:30 PM, Stefan Koch wrote: Hi I have successfully built my packages of the usbauth package suite for rawhide, f31 and epel8 branches. Currently, the packages are only part of the rawhide repo. How to get these packages copied to the epel8 and of course f31 repo? libusbauth-configparser: https://koji.fedoraproject.org/koji/packageinfo?packageID=30003 usbauth: https://koji.fedoraproject.org/koji/packageinfo?packageID=30004 usbauth-notifier: https://koji.fedoraproject.org/koji/packageinfo?packageID=30005 You submit updates with bodhi: https://bodhi.fedoraproject.org/updates/new https://fedoraproject.org/wiki/Package_update_HOWTO -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
