Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Friday, December 13, 2019 1:34:29 PM MST Mike Pinkerton wrote: > On 13 Dec 2019, at 15:03, John M. Harris Jr wrote: > > > > On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote: > > > >> > >> > >> What? There are only two images that are release blocking for optical > >> media right now. > >> > >> > >> > >> Everything/x86_64/iso/Fedora-Everything-netinst-x86_64- > >> _RELEASE_MILESTONE_.i > >> so > >> Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64- > >> _RELEASE_MILESTONE_.i > >> so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking > >> > >> > >> > >> I'm suggesting one instead of zero. Whatever image you're saying you > >> must have is already non-blocking so I don't even understand what > >> you're complaining about now. > > > > > > > > This isn't something that *I* personally need. The only ISO image I > > personally > > need is the KDE Spin ISO, so you'd be correct. For end-users, > > there's no need > > for the complexity of the Everything image to be present, however. > > If the end > > user wants to install the GNOME Spin, they shouldn't have to jump > > through > > hoops and know what they're picking. > > > I would say that the Everything netinstall image is more useful than > the Workstation Live image: > > * netinstall is smaller > * netinstall can be used to install servers > * netinstall with updates repo enabled yields current system without > doing the almost inevitable post-install (from non-netinstall image) > update That'd be great experience for users that already know what they want. and have a NIC which is supported in mainline. It's also not an option for users installing in airgapped environments, users who don't have internet access or have bad internet service, among other common issues. It would NOT be a good experience for a user to grab a GNOME or KDE Spin DVD, attempt to boot, and not be able to boot it. -- 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
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Sat, 2019-12-14 at 02:30 +0100, Kevin Kofler wrote: > Simo Sorce wrote: > > Install from optical is not anymore release critical, that is evident. > > To whom? All the VM testing I do is always with -cdrom foo.iso, so it would > break my VM testing completely. And there is also real hardware that it > would break (and there, you cannot work around it by just changing some > command-line flags). So, the virtual vs. real thing here is actually a bit unclear at present. The criterion we're proposing dropping specifically talks about real, physical optical media: "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size"... But, if you look at the Basic and Beta criteria, neither of those actually talks about virtual media at all: they just talk about "USB sticks" (which also implies real physical USB stick, to me at least, and I wrote them :>). The virtualization criterion doesn't get into the nitty gritty of virtual media types, it just says "The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release." So if we somehow got a case where a release-blocking ISO booted as a virtual USB stick but not as a virtual DVD, that would actually be a fairly difficult case to call as a blocker, both as the criteria stand right now and if this Change was accepted. Essentially it would be a conditional violation of the virtualization criterion: it'd be broken *if you configure your VM to use the image as a virtual optical disc*, but not if you configure your VM to use the image as a virtual USB stick. As a conditional violation it'd be a subjective decision by whoever showed up to blocker review, and I wouldn't want to guess which way that decision would go, to be honest. I'd probably vote +1, but I dunno which way others would vote. So, while we're considering this Change proposal, we might actually also want to think about clarifying the virtual media requirements a bit in the criteria at the same time... -- 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: Drop Optical Media Release Criterion
On Fri, 2019-12-13 at 12:02 +0100, Miro Hrončok wrote: > On 12. 12. 19 21:37, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion > > > > = Drop Optical Media Release Criterion = > > > > == Summary == > > Proposal to make all Fedora optical media non-blocking. This means > > we'd stop blocking on bugs found during the installation of Fedora > > from optical media (like CDs and DVDs). This doesn't mean that > > installation from optical media would stop working, just that the > > Fedora Release wouldn't be blocked on any issues that can pop up in > > Fedora installation using this method. Installation from USB devices > > will remain blocking. > > Juts a random idea, not very thought-out: > > Could we keep optical media bugs reported by users as blocking, but not > require > it during validation testing? > > > aka: Fedora QE would no longer have to verify optical media works. > but: If a tester finds an optical media bug, it is still blocking. > > That would still have 2 of the 3 listed benefits. The remaining benefit is > arguable (is optical media a corner case? there are no corners on DVD). Personally speaking I don't really *like* this fudge, but yes, we *can* do it. We actually have one fudge of precisely this kind in the criteria right now, so there is a clear precedent. It's to do with Cockpit browser support: https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Cockpit_management_interface "Manual testing will occur on the Firefox/Fedora platform. It will not be performed on the Chrome/Fedora platform nor any of the Windows / OSX platforms mentioned above, but if issues in code related to Fedora / Cockpit (and not third-party software such as the third-party browsers) in meeting the functional criteria are reported against those platforms, they may block the release." -- 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: Drop Optical Media Release Criterion
On Sat, 2019-12-14 at 02:18 +0100, Kevin Kofler wrote: > Chris Murphy wrote: > > What? There are only two images that are release blocking for optical > > media right now. > > > > Everything/x86_64/iso/Fedora-Everything-netinst-x86_64- > _RELEASE_MILESTONE_.iso > > Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64- > _RELEASE_MILESTONE_.iso > > https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking > > Who decided this, when? It was decided on this list and test@ , in January 2017: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KICRVUS3YHNTLHY47O5A2XL2C5YMCFIH/ https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/HLXHEB364LOLFHB2RDX6K4DFA4VJIWMF/ https://fedoraproject.org/w/index.php?title=Releases/26/ReleaseBlocking&oldid=484517 Note, this isn't exactly a case of 'Workstation is more important than KDE'. Rather, the idea was that we can be more efficient in testing by only testing *one* live image, because all the live images are built exactly the same way, so if one boots there's really absolutely no reason all the others shouldn't boot too. Similarly for traditional installer images. So, we picked the Everything netinst as the 'representative' for traditional installer images, and the Workstation live as the 'representative' for live images; the idea is that if we just test those two, it 99.9% proves all the others will also boot. If this proposal is accepted, of course, the question becomes moot; but if it isn't, we can look at tweaking how this is explained in the wiki and test matrix, because this element is not really clear as things stand (and I'd forgotten it and had to re-read the threads to refresh my memory). -- 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: Drop Optical Media Release Criterion
Simo Sorce wrote: > Install from optical is not anymore release critical, that is evident. To whom? All the VM testing I do is always with -cdrom foo.iso, so it would break my VM testing completely. And there is also real hardware that it would break (and there, you cannot work around it by just changing some command-line flags). > The fact that "there are some machines that do not support USB booting" > self-explanatorily tells you it is a small minority of basically broken > hardware which should not block a whole release. Since this cannot be fixed in an update (at least as long as Respins are still considered unofficial), it should. 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: Drop Optical Media Release Criterion
Chris Murphy wrote: > What? There are only two images that are release blocking for optical > media right now. > > Everything/x86_64/iso/Fedora-Everything-netinst-x86_64- _RELEASE_MILESTONE_.iso > Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64- _RELEASE_MILESTONE_.iso > https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking Who decided this, when? To my knowledge, it was agreed that the KDE x86_64 Live should be release blocking. Nowhere was it agreed back then, nor ever since, that this should only apply to some types of physical (or virtual) media and not others. I hereby request that the KDE Live x86_64 be made release-blocking for optical media again, unless explicitly agreed otherwise with the KDE SIG. 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: [minimization] Feedback Pipeline feedback wanted
On Fri, 2019-12-13 at 11:17 -0800, Adam Williamson wrote: > > It...*could* also work for non-candidate (i.e. nightly) Pungi 4 > composes that have been garbage collected by retrieving the info from > PDC, but this thread has made me realize that's a path that I've sort > of shut off with some design choices and I need to think about how to > open it up again. So count me as thoroughly nerdsniped - I spent all of today coming up with a (somewhat icky) fix for this: https://pagure.io/fedora-qa/fedfind/c/3e7a261be9faf9045ac2a5b3ba648536af86b010?branch=master so with fedfind git master, the sample script now will also give you date for old composes that are no longer present on any mirror, but for which the metadata was uploaded to PDC. Try it with e.g. Fedora-Rawhide-20171230.n.1 . I also thought about the 'get image sizes for old releases that are still on the mirrors' problem a bit and came up with this: https://pagure.io/quick-fedora-mirror/pull-request/82 which basically enhances the magic file fedfind uses to *find* all the image files from old releases to include each file's size as well; if tibbs is OK with that change, I can enhance fedfind to use that info and include the size in the image dicts it synthesizes for old releases. -- 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: Drop Optical Media Release Criterion
On Fri, 13 Dec 2019 15:34:29 -0500 Mike Pinkerton wrote: > I would say that the Everything netinstall image is more useful than > the Workstation Live image: > > * netinstall is smaller > * netinstall can be used to install servers > * netinstall with updates repo enabled yields current system without > doing the almost inevitable post-install (from non-netinstall image) > update +1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Updates impossible from iOS
On Thu, Dec 12, 2019 at 3:09 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > I've just unpushed it and removed the bug reference. An update for > txt2man-1.6.0-7.el8 was already submitted by you 4 days ago: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aa7ab9e560 > Maybe that's the reason? > Yeah, my bad on that one. I just took over maintenance for all branches and forgot I already pushed the epel8 one, but I think my overall comments still stand. It should accept manual input without having to add a space or anything. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2019-12-13
On Fri, Dec 13, 2019 at 01:48:07PM -0600, Michael Cronenworth wrote: > On 12/13/19 1:42 PM, Aoife Moloney wrote: > > Red Hat does a 2 week end of year shutdown where nearly everyone is > > encouraged to spend time away from computers and family. > > I know that's not how you meant to say it, but the end result is pretty > funny. :) The computers, they ARE our family! Anyhow, I hope everyone has a relaxing and enjoyable holiday season, no matter if you spend it with computers, family, neither or both. :) 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: Drop Optical Media Release Criterion
On 13 Dec 2019, at 15:03, John M. Harris Jr wrote: On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote: What? There are only two images that are release blocking for optical media right now. Everything/x86_64/iso/Fedora-Everything-netinst-x86_64- _RELEASE_MILESTONE_.i so Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64- _RELEASE_MILESTONE_.i so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking I'm suggesting one instead of zero. Whatever image you're saying you must have is already non-blocking so I don't even understand what you're complaining about now. This isn't something that *I* personally need. The only ISO image I personally need is the KDE Spin ISO, so you'd be correct. For end-users, there's no need for the complexity of the Everything image to be present, however. If the end user wants to install the GNOME Spin, they shouldn't have to jump through hoops and know what they're picking. I would say that the Everything netinstall image is more useful than the Workstation Live image: * netinstall is smaller * netinstall can be used to install servers * netinstall with updates repo enabled yields current system without doing the almost inevitable post-install (from non-netinstall image) update -- Mike ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop Optical Media Release Criterion
On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote: > On Fri, Dec 13, 2019 at 10:24 AM John M. Harris Jr > wrote: > > > > > > On Thursday, December 12, 2019 10:52:15 PM MST Chris Murphy wrote: > > > > > We'll just have to see if there's an easy fix for the util-linux > > > commit that broke this, which is kinda what I'm expecting. But it > > > might be reasonable to have one specific optical media only image, > > > perhaps Everything ISO. And then simplify the other images. > > > > > > > > That would needlessly make it more complex than necessary to install from > > optical media. > > > What? There are only two images that are release blocking for optical > media right now. > > Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-_RELEASE_MILESTONE_.i > so > Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-_RELEASE_MILESTONE_.i > so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking > > I'm suggesting one instead of zero. Whatever image you're saying you > must have is already non-blocking so I don't even understand what > you're complaining about now. This isn't something that *I* personally need. The only ISO image I personally need is the KDE Spin ISO, so you'd be correct. For end-users, there's no need for the complexity of the Everything image to be present, however. If the end user wants to install the GNOME Spin, they shouldn't have to jump through hoops and know what they're picking. -- 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
Re: Fedora 32 System-Wide Change proposal: Stop shipping individual component libraries in clang-libs package
On 12/12/2019 03:32 PM, Dan Čermák wrote: > Ben Cotton writes: > > [snip] >> >> == Dependencies == >> The following packages depend on clang-libs and will need to be updated: >> >> * bcc >> * bpftrace >> * castxml >> * ccls > > ccls has already been fixed upstream to support building against > libclang-cpp.so (as openSUSE did the same switch earlier and ccls > suddenly became FTBFS in Tumbleweed). > Thanks for letting me know. When are you planning to rebase to the new version in rawhide? -Tom >> * clazy >> * gnome-builder >> * ispc >> * kdevelop >> * lldb >> * mesa >> * pocl >> * qt-creator >> * qt5-doctools >> * shiboken2 >> * tinygo > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Fri, Dec 13, 2019 at 10:24 AM John M. Harris Jr wrote: > > On Thursday, December 12, 2019 10:52:15 PM MST Chris Murphy wrote: > > We'll just have to see if there's an easy fix for the util-linux > > commit that broke this, which is kinda what I'm expecting. But it > > might be reasonable to have one specific optical media only image, > > perhaps Everything ISO. And then simplify the other images. > > That would needlessly make it more complex than necessary to install from > optical media. What? There are only two images that are release blocking for optical media right now. Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-_RELEASE_MILESTONE_.iso Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-_RELEASE_MILESTONE_.iso https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking I'm suggesting one instead of zero. Whatever image you're saying you must have is already non-blocking so I don't even understand what you're complaining about now. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: CPE Weekly: 2019-12-13
On 12/13/19 1:42 PM, Aoife Moloney wrote: Red Hat does a 2 week end of year shutdown where nearly everyone is encouraged to spend time away from computers and family. I know that's not how you meant to say it, but the end result is pretty funny. :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop Optical Media Release Criterion
On Fri, Dec 13, 2019 at 4:03 AM Miro Hrončok wrote: > > On 12. 12. 19 21:37, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion > > > > = Drop Optical Media Release Criterion = > > > > == Summary == > > Proposal to make all Fedora optical media non-blocking. This means > > we'd stop blocking on bugs found during the installation of Fedora > > from optical media (like CDs and DVDs). This doesn't mean that > > installation from optical media would stop working, just that the > > Fedora Release wouldn't be blocked on any issues that can pop up in > > Fedora installation using this method. Installation from USB devices > > will remain blocking. > > Juts a random idea, not very thought-out: > > Could we keep optical media bugs reported by users as blocking, but not > require > it during validation testing? > > > aka: Fedora QE would no longer have to verify optical media works. > but: If a tester finds an optical media bug, it is still blocking. > > That would still have 2 of the 3 listed benefits. The remaining benefit is > arguable (is optical media a corner case? there are no corners on DVD). I think it could be reasonable for Fedora QA to only have automated testing, where VM's in openQA use the qemu DVD/CD device, and still block on release if any of those tests fail. But not require Fedora QA to actually buy and burn optical media and do physical tests. Of course it's possible the qemu device doesn't discover bugs that would affect real optical devices, and therefore users who claim they need this functionality really should be testing it, not expecting others to do this. And I also think the late blockers rule should apply to it, so testing needs to be done early not only at the last few days before final release. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
CPE Weekly: 2019-12-13
Hi everyone, Welcome to the CPE team weekly project update mail! Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. Note: This document is currently built from individual reports rolled into a document which we edit and copy into a final document. We are aware that this causes problems with some email readers, and are working on a method to make this less problematic. High Level Project Updates: Fedora Production issues with Bodhi: Bodhi is under investigation for misbehaving. Creating update can take a long time or just fail. The status can be tracked here https://status.fedoraproject.org/ Rawhide Gating Fixed: https://pagure.io/fedora-ci/general/issue/70 repoSpanner This has been turned off on Fedora side except for src.stg.fedoraproject.org The team are now working on whether to convert src.stg or redeploy Pagure Updates Pagure 5.8.1 has been released Pagure 5.8.1 has been pushed to staging & production Pagure-dist-git 1.5.1 and 1.5.2 has been released Pagure-dist-git 1.5.1 has been pushed to staging Pagure and 1.5.2 has been pushed to staging & production Fedora Docs Updates Merges: https://pagure.io/fedora-docs/quick-docs/pull-request/166 https://pagure.io/fedora-docs/quick-docs/pull-request/161 https://pagure.io/fedora-docs/quick-docs/pull-request/159 Fedora docs was published to localization stats to stage Community Fires Team Made the side-tag workflow work in stable releases Fixed the distgit-bugzilla-sync script New pagure and pagure-dist-git have been released and deployed Fix showing CI results on PR on dist-git Added a new API endpoint to Pagure to install and remove git hook Tiger Team Updates: OSBS Sprint focused on getting the aarch64 VMs in staging Deployed Fedora 30 on the VMs and started deploying OpenShift Currently blocked by the authentication to quay.io to get the aarch64 images. Focus for the next sprint is to have a working OpenShift on the aarch64 hardware. Bodhi CD Ability to build a docker image in quay.io on a push to github branch Ability to trigger a redeploy in openshift automatically after image has been rebuilt in quay Upgrade the database schema automatically with openshift deployment, instead of manually running ansible playbooks Application Retirements Elections Everything should be ready now to move Elections to Communishift Planning will start soon for a move date! Fedocal No progress on kanban board last seven weeks - looks abandoned https://teams.fedoraproject.org/project/fedora-calendar/kanban Jlanda’s permission error in communishift should be fixed now https://pagure.io/fedora-infrastructure/issue/8274 Another permission issue occurred during test Nuancier Benson Muite is now working on OIDC authentication The team have recommended to create a PR on Github to be able to see the progress PR from sebwoj - Porting to Fedora messaging Sebwoj is now working on adding scheme as part of the PR EPEL 8 Modularity EPEL 8 Modularity work tested in stage and was deployed to production on Tuesday 10th December EPEL 8 Playground Modularity work is on hold. Blocker: https://pagure.io/fm-orchestrator/issue/1541 CentOS Wiki.centos.org migration (last monday) Finishing templates for mailman ansible role (new look with community members) Preparing the next migration (sponsor relocates DC and new machines): www.centos.org (on track, to be announced) Forums (scheduled for next monday) Starting new ansible roles to automate deploy + upgrade of those migrated services Working on koji (cbs.dev) to see when we can import 8.1 content to let SIGs build against/for .el8 and .el8s (Stream) Collaborating with Artwork SIG for new design for http exposed services (new centos design) QA for 8-Stream and 8.1.1911 continues Misc Updates Tests to jms-messaging plugin are now successfully running & waiting for review Buildvmhost-01/02/03/04 has been reinstalled with rhel8 Buildvm-01 to 32 has been reinstalled Autocloud has been decommissioned ppc9-02 has been reinstalled with f31, and buildvm-ppc64le-01 to 09 ppc8-01 has been reinstalled with rhel8 F29 signed builds, updates, updates-testing, container, cloud composes in /mnt/koji/composes were cleaned up this week Holiday Season Shutdown Notices: Red Hat does a 2 week end of year shutdown where nearly everyone is encouraged to spend time aw
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Friday, December 13, 2019 12:16:12 PM MST Simo Sorce wrote: > And *all* old devices also have USB outlets, so it is unclear how this > would make Fedora not installable. > Any machine so old to have optical media but not USB is probably > already not working due to other factors like being i686 only). Simply having USB ports physically present is not sufficient to boot from USB. It is not supported by a surprisingly large number of systems, especially on systems from OEMs that roll their own UEFI firmware or first/second generation UEFI systems. Additionally, many mainline servers, even today, still do not support boot from USB, and many that do support booting from USB don't support booting from USB images over their remote management interfaces, only optical images to emulate an optical disk. -- 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
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Fri, 2019-12-13 at 10:28 -0700, John M. Harris Jr wrote: > On Friday, December 13, 2019 2:00:41 AM MST Frantisek Zatloukal wrote: > [snip] > > I don't expect to suddenly have F32 released with broken boot from > > optical media. > > If we don't want that to occur, optical media needs to remain a release > blocker. Are you volunteering to fix the blocker bugs? If not it should be on those that handle boot and QA to decide. Install from optical is not anymore release critical, that is evident. The fact that "there are some machines that do not support USB booting" self-explanatorily tells you it is a small minority of basically broken hardware which should not block a whole release. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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] Feedback Pipeline feedback wanted
On Fri, 2019-12-13 at 09:19 -0800, Kevin Fenzi wrote:
> It would be great if they could include the size +/- of all the images.
> Of course the most important ones would be boot.iso, workstation and
> server, but labs and spins could be very helpfull as well.
This sort of thing is what fedfind can help with. As an example of
where you'd start:
#!/bin/python3
import fedfind.release
import fedfind.helpers
rel = fedfind.release.get_release(cid="Fedora-Rawhide-20191213.n.0")
#rel = fedfind.release.get_release(1)
for img in rel.all_images:
imgid = fedfind.helpers.identify_image(img, out='string')
if img['disc_number'] > 1:
imgid += " disc {0}".format(img['disc_number'])
size = img.get('size')
if not size:
# this is something I should make fedfind handle...
# I swear it used to!
size = fedfind.helpers.get_size(img['direct_url'])
print("{0}: {1}".format(imgid, size))
hopefully it's pretty simple to see where to go from there. :) You can
try it with either of the 'rel' lines and it'll work...so you can
compare the image sizes from Fedora Core 1 with those from today's
Rawhide nightly, though they only have one image entirely in common
(Everything-boot-iso).
You can see I had to add a couple of bits to smoothly work with the
info for very old composes...I'll maybe tweak that a bit in fedfind
itself today, that code doesn't actually get *used* a lot so when I do
want to do something like this I usually find some issues that have
crept in.
This should work for any Pungi 4 compose that hasn't been garbage
collected yet, and also for all stable releases and old candidate
composes.
It...*could* also work for non-candidate (i.e. nightly) Pungi 4
composes that have been garbage collected by retrieving the info from
PDC, but this thread has made me realize that's a path that I've sort
of shut off with some design choices and I need to think about how to
open it up 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: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Fri, 2019-12-13 at 03:17 +0100, Kevin Kofler wrote: > Ben Cotton wrote: > > Proposal to make all Fedora optical media non-blocking. This means > > we'd stop blocking on bugs found during the installation of Fedora > > from optical media (like CDs and DVDs). This doesn't mean that > > installation from optical media would stop working, just that the > > Fedora Release wouldn't be blocked on any issues that can pop up in > > Fedora installation using this method. Installation from USB devices > > will remain blocking. > > I am against this Change. This is clearly a special case of Fedora not being > installable at all on a significant subset of hardware. I do not think it is > acceptable to ship it that way. Significant how? I haven't seen optical media on new devices for many years now ... And *all* old devices also have USB outlets, so it is unclear how this would make Fedora not installable. Any machine so old to have optical media but not USB is probably already not working due to other factors like being i686 only). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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] Feedback Pipeline feedback wanted
On Thu, 2019-12-12 at 12:59 +0100, Adam Samalik wrote: > The Minimization Objective[1] has been going on for a while. There are two > high-level goals: making things smaller, and keeping things smaller. On the > keeping smaller side, the team prototyped a service called Feedback > Pipeline [2] that monitors use cases for their installation size and > dependencies, including a size history. This will help us see bigger > changes in size for things the community cares about [3]. Just a note: I've actually already been doing something similar for a while. The openQA tests record various information on an installed system after install completes, and check-compose performs some analysis on this information. Significant changes are included in the 'compose check report' emails sent to this list and test@ . For instance, a notable change in the size of the installed system is reported, as are changes to the installed package set, or to the set of default-enabled system services. https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/master/f/tests/_collect_data.pm https://pagure.io/fedora-qa/check-compose/blob/master/f/check-compose#_306 I've always said I'm willing to enhance this in various ways (e.g. by having reporting in other ways than an email, like a web service), but no-one had really expressed any interest so far, so I haven't prioritized it. -- 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
koji builder status
Greetings. I just thought I would share a short status update on koji builders with everyone. As many of you know, we like to keep the Fedora koji builders on the current most recent stable Fedora release. This is to make sure we have compatible rpm, etc to build rawhide and all our stable updates. TLDR summary: All Fedora koji builders are now on Fedora 31 and are using only python3 (the hub is still python2 however). Due to a bug in the linux kernel on armv7, we never upgraded to Fedora 30 when it was released, so builders stayed on Fedora 29 for the last cycle. Happily that bug was tracked down and fixed and I have been moving them to Fedora 31 for the past month or so. Normally it doesn't take to long to reinstall everything (Thanks ansible!) but this time it's been a longer road due to: New aarch64 hardware that needed racking/cabling/setup (many thanks to Smooge for getting this done), firmware updates for most all hardware, RHEL8 reinstalls for virthosts that run buildvm's, and many other items. We still have pending: * Some more aarch64 hardware to bring online early in the new year. * A bug around armv7 buildvm's with more than 24GB memory. While thats being investigated all the buildvm-armv7 instances have just 24GB memory. * A bug around power9 hosts, causing our cloud/container image builds to fail. This was thought fixed, but doesn't seem to be yet. * Daily db dumps still cause slowness, likely in the new year we will schedule an outage and patition the problem tables. A few stats: 155 total enabled builders 47 x86_64 builders 32 ppc64le builders 32 aarch64 builders 27 armhfp builders 24 s390x builders Around 10,000 builds a month. Close to 1.1 million builds since fc6 days Happy building. 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: Drop Optical Media Release Criterion
On Friday, December 13, 2019 2:00:41 AM MST Frantisek Zatloukal wrote: [snip] > I don't expect to suddenly have F32 released with broken boot from > optical media. If we don't want that to occur, optical media needs to remain a release blocker. -- 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
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Thursday, December 12, 2019 10:52:15 PM MST Chris Murphy wrote: > The work around is part of testing the scope of the bug. It's not a > prescription for production use. This is precisely why I believe that optical media should continue to be release blocking. [snip] > We'll just have to see if there's an easy fix for the util-linux > commit that broke this, which is kinda what I'm expecting. But it > might be reasonable to have one specific optical media only image, > perhaps Everything ISO. And then simplify the other images. That would needlessly make it more complex than necessary to install from optical media. -- 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
Re: [minimization] Feedback Pipeline feedback wanted
On Thu, Dec 12, 2019 at 12:59:03PM +0100, Adam Samalik wrote: > The Minimization Objective[1] has been going on for a while. There are two > high-level goals: making things smaller, and keeping things smaller. On the > keeping smaller side, the team prototyped a service called Feedback > Pipeline [2] that monitors use cases for their installation size and > dependencies, including a size history. This will help us see bigger > changes in size for things the community cares about [3]. > > I already got some feedback from a few individuals I asked while developing > it, but I feel it's in a good enough state for a more broad feedback. So I > have a few questions: > > 1/ We plan to send weekly size updates to the devel list. Would that be > useful? What should they include? It would be great if they could include the size +/- of all the images. Of course the most important ones would be boot.iso, workstation and server, but labs and spins could be very helpfull as well. > > 2/ Regarding the use cases [4], especially the container ones, could people > please review and give feedback to those? Are all the packages there > actually required? I'm specifically looking at the "nss_wrapper" package > that drags in Perl and cmake which makes it huge. Which use case is that? All of the container ones? Sounds like a nice link to drop, but someone would need to find out the details. Why is it included? 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
Rust review swaps
Hello, I have a bunch of Rust package to review, would you please give some help in exchange of swaps? 1763433[1] _Review Request: rust-chunked_transfer - Encoder and decoder for HTTP chunked transfer coding (RFC 7230 § 4 _ 2019-12-07 21:27:57 UTC 1763459[2] _Review Request: rust-multipart - Backend-agnostic extension for HTTP libraries _ 2019-12-07 21:26:03 UTC 1763457[3] _Review Request: rust-nickel - Express _ 2019-12-07 21:23:22 UTC 1780765[4] _Review Request: rust-rustversion - Conditional compilation according to rustc compiler version _ 2019-12-07 12:47:28 UTC 1780769[5] _Review Request: rust-proc-macro-error-attr - Attribute macro for proc-macro-error crate _ 2019-12-07 12:47:28 UTC 1780772[6] _Review Request: rust-proc-macro-error - Almost drop-in replacement to panics in proc- macros _ 2019-12-07 12:46:17 UTC 1780784[7] _Review Request: rust-err-derive - Derive macro for `std::error::Error` _ 2019-12-07 12:44:39 UTC 1780797[8] _Review Request: rust-ivf - Simple ivf muxer _ 2019-12-07 00:21:38 UTC 1780793[9] _Review Request: rust-better-panic - Pretty panic backtraces inspired by Python's tracebacks _ 2019-12-06 23:51:54 UTC 1780789[10] _Review Request: rust-simd_helpers - Helpers to write more compact simd code _ 2019-12-06 22:25:10 UTC 1780783[11] _Review Request: rust-noop_proc_macro - No-op proc_macro, literally does nothing _ 2019-12-06 22:11:36 UTC 1780718[12] _Review Request: rust-findshlibs - Find the set of shared libraries loaded in the current process _ 2019-12-06 19:14:19 UTC 1780694[13] _Review Request: rust-arbitrary - Arbitrary trait for generating structured data from unstructured data _ 2019-12-06 16:31:07 UTC 1780425[14] _Review Request: rust-vergen - Generate version related functions _ 2019-12-05 23:37:29 UTC Best regards, Robert-André [1] https://bugzilla.redhat.com/show_bug.cgi?id=1763433 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1763459 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1763457 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1780765 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1780769___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop Optical Media Release Criterion
On Thu, Dec 12, 2019 at 07:59:54PM -0600, Richard Shaw wrote: Ok, obvious question first... Has this caused any problems? When was the last time this failed? The latter part is for selfish reasons... I still have one (decent) computer with primitive EFI BIOS that will only boot UEFI from optical media, not from USB (weird, I know). I also want optical media for some systems, but the testing and verification cycle for that for each release takes a lot of effort. It's easier to disconnect that from the release process and have it come along after the fact once the churn slows down and the rest of the release is taken care of. In my experience, there have *always* been boot media problems at the end of every release cycle. Some are solvable, others are not. -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20191213.n.0 changes
OLD: Fedora-Rawhide-20191212.n.1 NEW: Fedora-Rawhide-20191213.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 4 Dropped packages:2 Upgraded packages: 37 Downgraded packages: 0 Size of added packages: 8.89 MiB Size of dropped packages:22.34 MiB Size of upgraded packages: 1.16 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 2.75 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: gnome-monitor-config-0-0.1.20190520.gitbc2f76c.fc32 Summary: GNOME Monitor Configuration Tool RPMs:gnome-monitor-config Size:153.85 KiB Package: js-1:1.8.5-37.fc32 Summary: JavaScript interpreter and libraries RPMs:js js-devel Size:8.59 MiB Package: pmemkv-1.0.1-1.fc32 Summary: Key/Value Datastore for Persistent Memory RPMs:pmemkv pmemkv-devel Size:139.27 KiB Package: whipper-plugin-eaclogger-0.5.0-1.fc32 Summary: Whipper plugin to provide EAC style log reports RPMs:whipper-plugin-eaclogger Size:17.54 KiB = DROPPED PACKAGES = Package: owncloud-9.1.5-3.fc28 Summary: Private file sync and share server RPMs:owncloud owncloud-httpd owncloud-mysql owncloud-nginx owncloud-postgresql owncloud-sqlite Size:22.27 MiB Package: vim-vimoutliner-0.4.0-11.fc31 Summary: Script for building an outline editor on top of Vim RPMs:vim-vimoutliner Size:64.76 KiB = UPGRADED PACKAGES = Package: R-3.6.2-1.fc32 Old package: R-3.6.1-3.fc32 Summary: A language for data analysis and graphics RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath libRmath-devel libRmath-static Size: 345.03 MiB Size change: 9.45 MiB Changelog: * Thu Dec 12 2019 Tom Callaway - 3.6.2-1 - update to 3.6.2 - disable tests on all non-intel arches - fix powerpc64 Package: apache-commons-codec-1.13-1.fc32 Old package: apache-commons-codec-1.11-7.fc31 Summary: Implementations of common encoders and decoders RPMs: apache-commons-codec apache-commons-codec-javadoc Size: 435.99 KiB Size change: 19.03 KiB Changelog: * Thu Dec 12 2019 Mat Booth - 1.13-1 - Update to upstream version 1.13 Package: cppcheck-1.89-2.fc32 Old package: cppcheck-1.88-5.fc32 Summary: Tool for static C/C++ code analysis RPMs: cppcheck cppcheck-gui cppcheck-htmlreport Size: 15.67 MiB Size change: 608.06 KiB Changelog: * Sat Dec 07 2019 Steve Grubb - 1.89-1 - New upstream release 1.89 * Thu Dec 12 2019 Steve Grubb - 1.89-2 - Add "-fsigned-char" to CXXFLAGS, to make tests pass - https://trac.cppcheck.net/ticket/9359 Package: edid-decode-0-3.20191212gite719d040.fc32 Old package: edid-decode-0-3.20191202git5dc6e53a.fc32 Summary: Decode EDID data in human-readable format RPMs: edid-decode Size: 429.75 KiB Size change: 98.47 KiB Changelog: * Thu Dec 12 2019 Yanko Kaneti - 0-3.20191212gite719d040 - New snapshot. Add license Package: erfa-1.7.0-1.fc32 Old package: erfa-1.6.0-1.fc32 Summary: Essential Routines for Fundamental Astronomy RPMs: erfa erfa-devel Size: 964.13 KiB Size change: -534 B Changelog: * Thu Dec 12 2019 Sergio Pascual - 1.7.0-1 - New upstream version (1.7.0) Package: felix-gogo-runtime-1.1.0-4.fc32 Old package: felix-gogo-runtime-1.1.0-3.fc31 Summary: Apache Felix Gogo command line shell for OSGi RPMs: felix-gogo-runtime felix-gogo-runtime-javadoc Size: 271.43 KiB Size change: 47 B Changelog: * Thu Dec 12 2019 Mat Booth - 1.1.0-4 - Fix license tag to include MIT Package: fonttools-4.2.2-1.fc32 Old package: fonttools-4.2.0-1.fc32 Summary: Tools to manipulate font files RPMs: fonttools python3-fonttools Size: 1.24 MiB Size change: 1023 B Changelog: * Fri Dec 13 2019 Parag Nemade - 4.2.2-1 - Update to 4.2.2 version (#1782256) Package: glassfish-el-3.0.1-0.12.b08.fc32 Old package: glassfish-el-3.0.1-0.11.b08.fc31 Summary: J2EE Expression Language Implementation RPMs: glassfish-el glassfish-el-api glassfish-el-javadoc Size: 365.54 KiB Size change: -94.11 KiB Changelog: * Fri Sep 20 2019 Mat Booth - 3.0.1-0.12.b08 - Specify CDDL version on subpackages Package: icu4j-1:64.2-3.fc32 Old package: icu4j-1:64.2-2.fc31 Summary: International Components for Unicode for Java RPMs: icu4j icu4j-charset icu4j-javadoc icu4j-localespi Size: 15.04 MiB Size change: 969 B Changelog: * Thu Dec 12 2019 Mat Booth - 1:64.2-3 - Tests take too long on 32bit arm Package: jetty-9.4.24-2.v20191120.fc32 Old package: jetty-9.4.19-2.v20190610.fc31 Summary: Java Webserver and Servlet Container RPMs: jetty jetty-client jetty-continuation jetty-http jetty-io jetty-jaas jetty-javadoc jetty-jmx jetty-security jetty-server jetty-servlet jetty-
Re: Self Introduction: Joerg Kastning
On Fri, Dec 13, 2019 13:36:58 +0100, jkastn...@my-it-brain.de wrote: > Hello to everyone, Hello Joerg, > My name is Joerg Kastning and I'm a Sysadmin who is currently working > for the Bielefeld University. > > On my carreer counter I have round about 15 years of expierience as > Sysadmin, DevOp and IT Project Manager. Using Linux since 2009 as a > user and working with it as a professional (more or less) since 2012. > Some of my Open Source Projects and the ones I have contributed to, > you could find at [0]. > > At the office I'm using Timewarrior (timew) to track the time I spend > on different topics. And it came to my mind that it would be nice to > package this software to be able to install it using the package > manager that I know. And why build the package only for me when I > could build it could get it into an official repository? > > So I did some reading [1] and have found Ankur who maintains timew for > Fedora. I've told him that I'm eager to learn the bits of package > building and maintainig and he agreed coaching me to become a > co-maintainer for timew. And here I am. Looking forward to learn new > things about the operating system I enjoy. Welcome to Fedora, again! Yes, please e-mail me whenever you need to, and please also feel free to discuss and query the community. The sum total of knowledge the community has is *orders* of magnitude more than mine :) -- 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
Review Swap
Anyone interested in a review swap? I've got the python-npyscreen package thats waiting for a review which I'd like to write a few applications using, but I'd like it integrated before I move to much farther forward: https://bugzilla.redhat.com/show_bug.cgi?id=1782532 Neil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20191213.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 14/165 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20191212.n.1): ID: 498035 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/498035 ID: 498038 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/498038 ID: 498054 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/498054 ID: 498071 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/498071 ID: 498083 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/498083 ID: 498084 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/498084 ID: 498092 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/498092 ID: 498101 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/498101 Old failures (same test failed in Fedora-Rawhide-20191212.n.1): ID: 498029 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/498029 ID: 498032 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/498032 ID: 498093 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/498093 ID: 498109 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/498109 ID: 498111 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/498111 ID: 498117 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/498117 ID: 498181 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/498181 Soft failed openQA tests: 18/165 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20191212.n.1): ID: 498020 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/498020 ID: 498030 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/498030 ID: 498033 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/498033 ID: 498049 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/498049 ID: 498051 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/498051 ID: 498067 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/498067 ID: 498072 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/498072 ID: 498085 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/498085 ID: 498090 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/498090 ID: 498105 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/498105 ID: 498179 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/498179 ID: 498186 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/498186 Old soft failures (same test soft failed in Fedora-Rawhide-20191212.n.1): ID: 498141 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/498141 ID: 498147 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/498147 ID: 498148 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/498148 ID: 498166 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/498166 ID: 498167 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/498167 ID: 498183 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/498183 Passed openQA tests: 133/165 (x86_64) New passes (same test not passed in Fedora-Rawhide-20191212.n.1): ID: 498024 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/498024 ID: 498025 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/498025 ID: 498026 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests
Re: HEADS-UP: poetry 1.0.0 now available in rawhide
On Fri, Dec 13, 2019 at 2:09 PM Neal Gompa wrote: > > On Fri, Dec 13, 2019 at 7:45 AM Fabio Valentini wrote: > > > > Hi everybody, > > > > I've been tracking beta releases of poetry for a while now, and a few > > hours ago, 1.0.0 was finally released to GitHub [0] and pypi [1]. > > > > I've made packages of beta releases available on COPR [2] for some > > time, and I am not aware of any issues with the 1.0.0 release (rather, > > it fixes some issues that are present in 0.12.17, and also makes it > > possible to drop two downstream patches). > > > > poetry 1.0.0 is now available in rawhide, and from the linked COPR > > [2]. I don't plan to update it in fedora 31 (yet), but if there is > > interest, I can push the three necessary updates (clikit 0.4.1, cleo > > 0.7.6, poetry 1.0.0) to fedora 31, as well. For now, packages for > > fedora 31 are available on COPR [2] for testing purposes. > > > I'd like to use poetry 1.0.0 on Fedora 31, so it'd be pretty great if > you could do that. I've been itching to start using poetry in more > places! > > Anyway, thanks for bringing us the latest poetry! :) Alright - after fixing a small packaging issue in python3-CacheControl (thanks, Neal!), I've pushed the necessary updates to fedora 31 as well. CacheControl packaging fix: https://bodhi.fedoraproject.org/updates/FEDORA-2019-337dd1bcda poetry 1.0.0 and dependencies: https://bodhi.fedoraproject.org/updates/FEDORA-2019-24c9d17287 This update should not cause any regressions, especially not for package builds, since poetry is not yet used for builds in f31 at all, and in rawhide, only one package uses it (python-chaospy), but it looks like it does not use the poetry functionality that was changed in a backwards-incompatible way between 0.12.17 and 1.0.0. Fabio > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: eit.c:394:13: error: 'stime' was not declared in this scope; did you mean 'ctime'?
I tried to compile the vdr with the following patch, unfortunately it fails
with the following error message.
eit.c:25:18: error: missing binary operator before token "("
25 | #if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_31)
| ^
make: *** Deleting file '.dependencies'
--- a/eit.c.orig2019-12-13 12:45:00.202346585 +0100
+++ b/eit.c 2019-12-13 12:46:20.027353073 +0100
@@ -18,6 +18,32 @@
#include "libsi/section.h"
#include "libsi/descriptor.h"
+
+
+#include
+
+#if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_31)
+
+#include
+
+/* Set the system clock to *WHEN. */
+
+int
+attribute_compat_text_section
+__stime (const time_t *when)
+ {
+ struct timespec ts;
+ ts.tv_sec = *when;
+ ts.tv_nsec = 0;
+
+ return __clock_settime (CLOCK_REALTIME, &ts);
+ }
+
+compat_symbol (libc, __stime, stime, GLIBC_2_0);
+#endif
+
+
+
#define VALID_TIME (31536000 * 2) // two years
#define DBGEIT 0
Regards
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS-UP: poetry 1.0.0 now available in rawhide
On Fri, Dec 13, 2019 at 7:45 AM Fabio Valentini wrote: > > Hi everybody, > > I've been tracking beta releases of poetry for a while now, and a few > hours ago, 1.0.0 was finally released to GitHub [0] and pypi [1]. > > I've made packages of beta releases available on COPR [2] for some > time, and I am not aware of any issues with the 1.0.0 release (rather, > it fixes some issues that are present in 0.12.17, and also makes it > possible to drop two downstream patches). > > poetry 1.0.0 is now available in rawhide, and from the linked COPR > [2]. I don't plan to update it in fedora 31 (yet), but if there is > interest, I can push the three necessary updates (clikit 0.4.1, cleo > 0.7.6, poetry 1.0.0) to fedora 31, as well. For now, packages for > fedora 31 are available on COPR [2] for testing purposes. > I'd like to use poetry 1.0.0 on Fedora 31, so it'd be pretty great if you could do that. I've been itching to start using poetry in more places! Anyway, thanks for bringing us the latest poetry! :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
HEADS-UP: poetry 1.0.0 now available in rawhide
Hi everybody, I've been tracking beta releases of poetry for a while now, and a few hours ago, 1.0.0 was finally released to GitHub [0] and pypi [1]. I've made packages of beta releases available on COPR [2] for some time, and I am not aware of any issues with the 1.0.0 release (rather, it fixes some issues that are present in 0.12.17, and also makes it possible to drop two downstream patches). poetry 1.0.0 is now available in rawhide, and from the linked COPR [2]. I don't plan to update it in fedora 31 (yet), but if there is interest, I can push the three necessary updates (clikit 0.4.1, cleo 0.7.6, poetry 1.0.0) to fedora 31, as well. For now, packages for fedora 31 are available on COPR [2] for testing purposes. Fabio [0]: https://github.com/python-poetry/poetry/releases/tag/1.0.0 [1]: https://pypi.org/project/poetry/1.0.0/ [2]: https://copr.fedorainfracloud.org/coprs/decathorpe/poetry-1.0.0/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Joerg Kastning
Hello to everyone, My name is Joerg Kastning and I'm a Sysadmin who is currently working for the Bielefeld University. On my carreer counter I have round about 15 years of expierience as Sysadmin, DevOp and IT Project Manager. Using Linux since 2009 as a user and working with it as a professional (more or less) since 2012. Some of my Open Source Projects and the ones I have contributed to, you could find at [0]. At the office I'm using Timewarrior (timew) to track the time I spend on different topics. And it came to my mind that it would be nice to package this software to be able to install it using the package manager that I know. And why build the package only for me when I could build it could get it into an official repository? So I did some reading [1] and have found Ankur who maintains timew for Fedora. I've told him that I'm eager to learn the bits of package building and maintainig and he agreed coaching me to become a co-maintainer for timew. And here I am. Looking forward to learn new things about the operating system I enjoy. Best regards, Joerg [0] https://github.com/Tronde [1] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop Optical Media Release Criterion
On Fri, Dec 13, 2019, at 6:02 AM, Miro Hrončok wrote: > On 12. 12. 19 21:37, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion > > > > = Drop Optical Media Release Criterion = > > > > == Summary == > > Proposal to make all Fedora optical media non-blocking. This means > > we'd stop blocking on bugs found during the installation of Fedora > > from optical media (like CDs and DVDs). This doesn't mean that > > installation from optical media would stop working, just that the > > Fedora Release wouldn't be blocked on any issues that can pop up in > > Fedora installation using this method. Installation from USB devices > > will remain blocking. > > Juts a random idea, not very thought-out: > > Could we keep optical media bugs reported by users as blocking, but not > require > it during validation testing? > I'm against the change as- is, but I could support this. I use optical media extensively for reasons beyond my control. It's also useful for virtual CD on hardware via IPMI/iDRAC, depending on the vendor. I'll try to get back to help fill out the test matrix as I had done years ago. > > aka: Fedora QE would no longer have to verify optical media works. > but: If a tester finds an optical media bug, it is still blocking. > +1 V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Working fedora-active-user script?
On Fri, Dec 13, 2019 at 12:17 PM Frank R Dana Jr. wrote: > > Hmmm. If there's a plan is to get it working again relatively soon, though, I > should probably withdraw my PR[1] to remove mention of it from the > Non-Responsive Maintainer Policy. (I figured, doesn't make sense to suggest a > tool that can't actually be used...) > > [1]: https://pagure.io/fesco/fesco-docs/pull-request/23 The fedora_cert missing dependency issue was fixed on the latest master branch [1], though the README is not updated yet. I believe that the script is actually used now. [1] https://github.com/pypingou/fedora-active-user -- Jun | He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Removing %py[23]?_(install|build)_egg macros
Hello, I'd like to remove the following macros from rawhide: %py_build_egg %py2_build_egg %py3_build_egg %py_install_egg %py2_install_egg %py3_install_egg Nothing in Fedora uses them. I would also remove this page: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Eggs/ https://fedoraproject.org/wiki/Packaging:Python_Eggs To my best knowledge, there are no packaged eggs in Fedora, and Python upstream has moved away from eggs long time ago. I'd like to focus on packaging wheels instead, via https://src.fedoraproject.org/rpms/pyproject-rpm-macros Thoughts? -- 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: Announcing new anitya integration and de-orphaning process
Hi On Mon, Dec 9, 2019 at 11:43 AM Pierre-Yves Chibon wrote: > > `Monitoring` means: you get a bugzilla ticket > `Monitoring and scrach builds` means: you get the bugzilla ticket and an > attempt to do a scratch build for the new version > I was wondering how hard it would be to open a pull request if a scratch build was successful. For minor version bumps, this can be helpful for maintainers Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Working fedora-active-user script?
Hmmm. If there's a plan is to get it working again relatively soon, though, I should probably withdraw my PR[1] to remove mention of it from the Non-Responsive Maintainer Policy. (I figured, doesn't make sense to suggest a tool that can't actually be used...) [1]: https://pagure.io/fesco/fesco-docs/pull-request/23 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
New NeuroFedora public mailing list for discussions: neurofed...@lists.fp.o
Hello everyone, Apologies for the cross-post. As the number of packages maintained by the NeuroFedora team has increased, so have the bugs, and notifications from Bugzilla. Since the notifications hamper discussion, we've decided to use a different mailing list for them. So: neurofed...@lists.fedoraproject.org is now the primary mailing list for discussion, support, and everything else human. The current list at neuro-...@lists.fedoraproject.org will be limited to Bugzilla notifications only. Only package maintainers may subscribe to this list, and for security, the archives will also be made private. If you are currently subscribed to neuro-...@lists.fedoraproject.org, you needn't do anything. I will move your subscription over to neurofed...@lists.fedoraproject.org. You will need to update your e-mail filters, however. -- 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: stime() is no longer declared in time.h for rawhide
Yup. To be precise, quoting from the NEWS entry added for the change: * The obsolete function stime is no longer available to newly linked binaries and it has been removed from header. This function has been deprecated in favor of clock_settime. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop Optical Media Release Criterion
On 12. 12. 19 21:37, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion = Drop Optical Media Release Criterion = == Summary == Proposal to make all Fedora optical media non-blocking. This means we'd stop blocking on bugs found during the installation of Fedora from optical media (like CDs and DVDs). This doesn't mean that installation from optical media would stop working, just that the Fedora Release wouldn't be blocked on any issues that can pop up in Fedora installation using this method. Installation from USB devices will remain blocking. Juts a random idea, not very thought-out: Could we keep optical media bugs reported by users as blocking, but not require it during validation testing? aka: Fedora QE would no longer have to verify optical media works. but: If a tester finds an optical media bug, it is still blocking. That would still have 2 of the 3 listed benefits. The remaining benefit is arguable (is optical media a corner case? there are no corners on DVD). -- 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: Maintainer contact check for Chris Grau (cgrau)
Yeah, problem is I posted this using HyperKitty, which doesn't give me any way to do that. 😕 The bugzilla maintainer check auto-mailed Chris's registered address, though, so there's been an attempt at direct contact. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: stime() is no longer declared in time.h for rawhide
ok, that means stime () has been deprecated in glibc 2.31 and replaced with clock_settime (). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Maintainer contact check for Chris Grau (cgrau)
Am 13.12.19 um 07:29 schrieb Frank R Dana Jr.: > As a follow-up to RHBZ 1779063 and in accordance with the non-responsive > maintainer policy[1], You should also cc Chris - maybe he is no longer actively following fedora-devel. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop Optical Media Release Criterion
On Thu, Dec 12, 2019 at 11:31 PM Adam Williamson wrote: > On Thu, 2019-12-12 at 15:37 -0500, Ben Cotton wrote: > > > > == Scope == > > * Proposal owners: Change [[Releases/32/ReleaseBlocking]] to indicate > > we no longer block on optical media, change Validation Testing > > Matrices > > I don't think this is quite right. The ReleaseBlocking page would > likely not change, as the *images* themselves would remain release > blocking, we just would no longer block on them working when written to > physical optical media. > > Rather, as well as the Installation matrix, this would require changing > the release criteria, specifically 'Supported media types' for this > Final criterion: > > > https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Release-blocking_images_must_boot > > Proposal updated to reflect Final Release Criteria page change. Thanks, as for the ReleaseBlocking page, there is "optical boot is release blocking" column with "yes" for mentioned images, which would change to "no", should this change be accepted. > The proposal to drop the optical requirement entirely was first floated > by Matthew Miller in September 2018 on test@ , and there is a long > discussion thread following that proposal: > > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/E5RJTWF6VZLQFWHB5IBAXBSQIB57SJSY/#E5RJTWF6VZLQFWHB5IBAXBSQIB57SJSY > > which may be helpful for context. > > Link to the thread has been added to the proposal page. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop Optical Media Release Criterion
On Fri, Dec 13, 2019 at 9:28 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 12.12.2019 21:37, Ben Cotton wrote: > > Proposal to make all Fedora optical media non-blocking. This means > > we'd stop blocking on bugs found during the installation of Fedora > > from optical media (like CDs and DVDs). This doesn't mean that > > installation from optical media would stop working, just that the > > Fedora Release wouldn't be blocked on any issues that can pop up in > > Fedora installation using this method. Installation from USB devices > > will remain blocking. > > I'm strongly against this change. There are still lots of working > hardware that does not support booting from USB in UEFI mode (first wave > of hardware with UEFI BIOS). > > Fedora should be installable on all supported hardware. > > On Fri, Dec 13, 2019 at 3:19 AM Kevin Kofler wrote: > Ben Cotton wrote: > > Proposal to make all Fedora optical media non-blocking. This means > > we'd stop blocking on bugs found during the installation of Fedora > > from optical media (like CDs and DVDs). This doesn't mean that > > installation from optical media would stop working, just that the > > Fedora Release wouldn't be blocked on any issues that can pop up in > > Fedora installation using this method. Installation from USB devices > > will remain blocking. > > I am against this Change. This is clearly a special case of Fedora not > being > installable at all on a significant subset of hardware. I do not think it > is > acceptable to ship it that way. > > This change is not aimed to make Fedora non-installable via CD/DVD. As it's written in the proposal, *"This doesn't mean that installation from optical media would stop working, just that the Fedora Release wouldn't be blocked on any issues that can pop up in Fedora installation using this method. " * Also, if you care about Fedora being installable from CD or DVD, you might want to help with testing. Bugs will be handled like any other bugs found in Fedora. No one apart from Fedora QE Team members filled F31 Final Validation Testing Matrix for optical media installation [0][1][2]. As for HW that does not support USB boot, there will always be some HW without USB boot support caused probably by firmware bugs. However, the vast majority of HW sold in last decade should support USB boot just fine. Even desktop I had in 2004 supported USB boot... This proposal would allow QE to focus more on areas which are exposed to the majority of users instead of having to spend limited time and resources by burning CDs and testing them just to make sure it works for fraction of user base. I don't expect to suddenly have F32 released with broken boot from optical media. [0] https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.3_Installation#Default_boot_and_install [1] https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.8_Installation#Default_boot_and_install [2] https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.9_Installation#Default_boot_and_install ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Qt 5.14 update plans?
Hi, On pátek 13. prosince 2019 3:04:37 CET Richard Shaw wrote: > Looks like Qt just released 5.14, I believe this officially supports Python > 3.8? So it would probably be a good idea to update Rawhide sooner rather > than later. I just finished update to Qt 5.13.2. I'm not sure about Qt 5.14 at this moment. First of all it was released yesterday so there might be potential regressions and second is that this Qt version will not be officially supported by Plasma 5.18, which means there might be incompatible changes, most likely Wayland related etc. I'm not saying it won't work, but upstream will test Plasma 5.18 against Qt 5.12 LTS and Qt 5.13 and it's guaranteed to work as expected. Also, reading notes about Qt for Python, it won't be released at least until next Monday. Notes: https://wiki.qt.io/Qt_for_Python_Development_Notes[1] Jan [1] https://wiki.qt.io/Qt_for_Python_Development_Notes ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop Optical Media Release Criterion
On 12.12.2019 21:37, Ben Cotton wrote: > Proposal to make all Fedora optical media non-blocking. This means > we'd stop blocking on bugs found during the installation of Fedora > from optical media (like CDs and DVDs). This doesn't mean that > installation from optical media would stop working, just that the > Fedora Release wouldn't be blocked on any issues that can pop up in > Fedora installation using this method. Installation from USB devices > will remain blocking. I'm strongly against this change. There are still lots of working hardware that does not support booting from USB in UEFI mode (first wave of hardware with UEFI BIOS). Fedora should be installable on all supported hardware. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: stime() is no longer declared in time.h for rawhide
On 13/12/2019 07:46, Martin Gansser wrote: was the stime () declaration moved in another header file ? What is the reason for this. Commit history explains: https://sourceware.org/git/?p=glibc.git;a=commit;h=12cbde1da But summary seems to be, as was said when the same question was asked yesterday, to use clock_settime instead. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
