Re: Update to last minute blocker bugs proposal (Rev:07242019)
On Fri, 2019-08-09 at 19:04 -0700, Adam Williamson wrote: > On Fri, 2019-08-09 at 18:26 -0700, Adam Williamson wrote: > > On Wed, 2019-07-24 at 10:04 -0400, pmkel...@frontier.com wrote: > > > I got feedback from Adam and Ben today; so the following changes have > > > been made: > > > > > > I have added a little paragraph at the beginning to say what a last > > > minute blocker bug is. I used freeze as the time anchor rather than a > > > meeting since that seems to be the most firm time constraint we work to. > > > Perhaps the review meetings could be anchored to the freeze as well. > > > There might be some merit to showing the critical meetings in the > > > schedule list that gets published. > > > > > > I changed "team" to "stakeholder groups" > > > > > > I removed "proposed" from places where it really didn't add anything. > > > > > > > > > Have a Great Day! > > > > > > Pat (tablepc) > > > > Thanks Pat! For future drafts, can you please just send them as plain > > text in line? It makes it more convenient to read them quickly. For the > > record, here is Pat's proposal: > > *snip* > > OK, so here is a new draft based on a kind of merge of Pat's recent > drafts and my earlier drafts. For the record, my previous draft was 555 > words, Pat's last draft is 258 words (without counting the paragraph > numbers and without any wikitext like mine has), and this is 445 words. > I think Pat's draft left out some necessary connective tissue, though > (like what exactly this concept is *for*, and details on how exactly > the review should be handled, and it kinda smooshed together the 'last > minute' and 'difficult to fix' concepts), so I don't think I can cut > much more. OK, so based on the follow-ups here, I went ahead and merged this draft, only with '7 days' changed to '5 days': https://fedoraproject.org/w/index.php?title=QA%3ASOP_blocker_bug_process&type=revision&diff=551137&oldid=503308 Thanks folks! > +++ DRAFT START +++ > > === Exceptional cases === > > Generally speaking, any bug that is agreed to be a violation of the > [[Fedora Release Criteria|release criteria]] should be accepted as a > blocker bug for the next relevant milestone release. However, bearing > in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis > on '''both''' time '''and''' quality, in some cases we may make an > exception. There are two main categories of bug that may be > 'exceptional': > > # '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or > fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone release > (Beta or Final) can be considered under this policy, as there are some > circumstances in which we believe it is not sensible to delay an > otherwise-impending release to fix a bug which would usually be > accepted as a blocker if discovered earlier. In these circumstances, > the bug can instead be accepted as a blocker for the ''next'' milestone > release. > # '''Difficult to fix blocker bugs''' - bugs which it may not be > practical to fix within a reasonable time frame for the release to be > made (due to e.g. complexity or resource constraints) > > The stakeholder groups must first agree, following the procedures > described above, that the bug violates the release criteria and so > would otherwise be accepted as a blocker bug for the imminent release. > > After that, the stakeholder groups may separately make a decision as to > whether to invoke this policy and consider delaying the blocker status > to a future milestone release. Anyone attending the meeting (or > otherwise taking part in the discussion, if it is being done outside of > a meeting) can suggest that this evaluation be done. In making the > decision, the following factors can be considered: > > * How prominently visible the bug will be > * How severe the consequences of the bug are > * How many users are likely to encounter the bug > * Whether the bug could or should have been proposed earlier in the > cycle > * Whether the current stable release is affected by the bug > * Whether delaying the release may give us an opportunity to carry out > other desirable work > * Possible effects of the expected delay on Fedora itself and also to > downstream projects > * Whether an additional delay to fix the bug, combined with any prior > delays in the cycle, results in the total delay becoming unacceptable > in regard to the [[Fedora_Release_Life_Cycle]] > > In almost all 'exceptional' cases, the bug should be accepted as a > blocker either for the very next milestone release, or for the > equivalent milestone for the next release (if it would not violate the > criteria for the very next milestone). For very complex '''difficult to > fix''' cases, a longer extension may be needed. > > +++ DRAFT END +++ > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___
Re: Proposing new release criteria
On 8/29/19 3:15 PM, Dusty Mabe wrote: > > On 8/29/19 2:36 PM, Daniel Walsh wrote: >> On 8/29/19 2:16 PM, Mairi Dulaney wrote: >>> On Lùna 29, 2019 aig 10:33:09m -0400, sgrìobh Dusty Mabe: I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1]. New section for Containers and Container tools: - A Fedora system can install the podman container runtime - The podman container runtime can pull/run a container from Fedora's registry as root - The podman container runtime can pull/run a container from Fedora's registry as a non-root user As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31). >>> Is Podman are only officially supported container runtime? >>> >>> What about, say, Docker? >> We no longer ship Docker, You need to get that from the vendor. We do >> ship Moby. But this is not ready for the cgroup change, nor is RUNC. > I think to the user a lot of people consider shipping moby as the same thing > as shipping docker. If you want docker you can still get it through moby. Sure, But Docker INC would prefer us to call it Moby... > Dusty > ___ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On 8/29/19 2:36 PM, Daniel Walsh wrote: > On 8/29/19 2:16 PM, Mairi Dulaney wrote: >> On Lùna 29, 2019 aig 10:33:09m -0400, sgrìobh Dusty Mabe: >>> I don't know the formal process for proposal but here is a shot at a bare >>> minimum >>> start for trying to add containers to the existing release criteria. This >>> is a suggestion >>> after we found podman can't pull containers from a registry in f31 [1]. >>> >>> New section for Containers and Container tools: >>> >>> - A Fedora system can install the podman container runtime >>> - The podman container runtime can pull/run a container from Fedora's >>> registry as root >>> - The podman container runtime can pull/run a container from Fedora's >>> registry as a non-root user >>> >>> As for the container I'd suggest the previous fedora release's container >>> (i.e. f30 for f31). >> Is Podman are only officially supported container runtime? >> >> What about, say, Docker? > We no longer ship Docker, You need to get that from the vendor. We do > ship Moby. But this is not ready for the cgroup change, nor is RUNC. I think to the user a lot of people consider shipping moby as the same thing as shipping docker. If you want docker you can still get it through moby. Dusty ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On 8/29/19 2:16 PM, Mairi Dulaney wrote: > On Lùna 29, 2019 aig 10:33:09m -0400, sgrìobh Dusty Mabe: >> I don't know the formal process for proposal but here is a shot at a bare >> minimum >> start for trying to add containers to the existing release criteria. This is >> a suggestion >> after we found podman can't pull containers from a registry in f31 [1]. >> >> New section for Containers and Container tools: >> >> - A Fedora system can install the podman container runtime >> - The podman container runtime can pull/run a container from Fedora's >> registry as root >> - The podman container runtime can pull/run a container from Fedora's >> registry as a non-root user >> >> As for the container I'd suggest the previous fedora release's container >> (i.e. f30 for f31). > Is Podman are only officially supported container runtime? > > What about, say, Docker? We no longer ship Docker, You need to get that from the vendor. We do ship Moby. But this is not ready for the cgroup change, nor is RUNC. > As for which container(s) should be runable, I'd think the criteria > should mirror the current virt criteria, e.g., self hosting, and as a > container-on-previous-release. I also reckon we should mirror the > virt criteria when it comes to a runtime, and 'recommend' a runtime > rather than require a specific one. > > -- > Tapadh leabh, > Mairi Dulaney. > ___ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On 8/29/19 2:28 PM, Adam Williamson wrote: > On Thu, 2019-08-29 at 20:15 +0200, Julen Landa Alustiza wrote: >> Could we go on a more generic fashion? >> >> Something like "Supported container engines must work on their basic >> features on all the blocker deliverables were they are installed by >> default" >> >> Our supported engines are, podman? cri-o? > We could, but I think it's only necessary if there are either a *lot* > of criteria and/or we decide to have more than one. > > Matthew, Dusty, any thoughts on whether we would want to support any > beyond podman? So far docker and cri-o have been brought up. My guess > would be we'd probably want podman and not docker, but I'm not sure > about cri-o... Well CRI-O and Kubernetes are not ready for the CGRoupsV2 change, Nor is Moby. I would say podman and buildah should work. We need changes upstream to get the other packages to be supported. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On Thu, 2019-08-29 at 20:15 +0200, Julen Landa Alustiza wrote: > Could we go on a more generic fashion? > > Something like "Supported container engines must work on their basic > features on all the blocker deliverables were they are installed by > default" > > Our supported engines are, podman? cri-o? We could, but I think it's only necessary if there are either a *lot* of criteria and/or we decide to have more than one. Matthew, Dusty, any thoughts on whether we would want to support any beyond podman? So far docker and cri-o have been brought up. My guess would be we'd probably want podman and not docker, but I'm not sure about cri-o... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On Lùna 29, 2019 aig 10:33:09m -0400, sgrìobh Dusty Mabe: > I don't know the formal process for proposal but here is a shot at a bare > minimum > start for trying to add containers to the existing release criteria. This is > a suggestion > after we found podman can't pull containers from a registry in f31 [1]. > > New section for Containers and Container tools: > > - A Fedora system can install the podman container runtime > - The podman container runtime can pull/run a container from Fedora's > registry as root > - The podman container runtime can pull/run a container from Fedora's > registry as a non-root user > > As for the container I'd suggest the previous fedora release's container > (i.e. f30 for f31). Is Podman are only officially supported container runtime? What about, say, Docker? As for which container(s) should be runable, I'd think the criteria should mirror the current virt criteria, e.g., self hosting, and as a container-on-previous-release. I also reckon we should mirror the virt criteria when it comes to a runtime, and 'recommend' a runtime rather than require a specific one. -- Tapadh leabh, Mairi Dulaney. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
Could we go on a more generic fashion? Something like "Supported container engines must work on their basic features on all the blocker deliverables were they are installed by default" Our supported engines are, podman? cri-o? On August 29, 2019 6:40:21 PM GMT+02:00, Matthew Miller wrote: >On Thu, Aug 29, 2019 at 11:45:44AM -0400, Dusty Mabe wrote: >> Certainly anywhere where podman is shipped on media. Does podman ship >in the server DVD? yes [1] >> It looks like workstation also ships it if I'm reading the logs [2] >correctly. > >Yeah, it's needed for Toolbox, which is a vital feature for Silverblue >but >also one we want to encourage on general Workstation as well. > >Pretty sure it's also required for IoT. Julen Landa Alustiza ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On Thu, Aug 29, 2019 at 11:45:44AM -0400, Dusty Mabe wrote: > Certainly anywhere where podman is shipped on media. Does podman ship in the > server DVD? yes [1] > It looks like workstation also ships it if I'm reading the logs [2] correctly. Yeah, it's needed for Toolbox, which is a vital feature for Silverblue but also one we want to encourage on general Workstation as well. Pretty sure it's also required for IoT. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On 8/29/19 11:13 AM, Adam Williamson wrote: > On Thu, 2019-08-29 at 10:33 -0400, Dusty Mabe wrote: >> I don't know the formal process for proposal > > Congratulations, you found it - mail this list, ideally including at > least one of the strings 'criter' or 'propos'. :P > >> but here is a shot at a bare minimum >> start for trying to add containers to the existing release criteria. This is >> a suggestion >> after we found podman can't pull containers from a registry in f31 [1]. >> >> New section for Containers and Container tools: >> >> - A Fedora system can install the podman container runtime >> - The podman container runtime can pull/run a container from Fedora's >> registry as root >> - The podman container runtime can pull/run a container from Fedora's >> registry as a non-root user >> >> As for the container I'd suggest the previous fedora release's container >> (i.e. f30 for f31). > > Do you think this should apply to all release-blocking installs, or > should it be specific to e.g. release-blocking cloud images? > Certainly anywhere where podman is shipped on media. Does podman ship in the server DVD? yes [1] It looks like workstation also ships it if I'm reading the logs [2] correctly. Dusty [1] https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-31/compose/Server/x86_64/os/Packages/p/podman-1.5.1-2.16.dev.gitce64c14.fc31.x86_64.rpm [2] https://kojipkgs.fedoraproject.org//work/tasks/9101/37319101/anaconda-packaging.log ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On Thu, 2019-08-29 at 10:33 -0400, Dusty Mabe wrote: > I don't know the formal process for proposal Congratulations, you found it - mail this list, ideally including at least one of the strings 'criter' or 'propos'. :P > but here is a shot at a bare minimum > start for trying to add containers to the existing release criteria. This is > a suggestion > after we found podman can't pull containers from a registry in f31 [1]. > > New section for Containers and Container tools: > > - A Fedora system can install the podman container runtime > - The podman container runtime can pull/run a container from Fedora's > registry as root > - The podman container runtime can pull/run a container from Fedora's > registry as a non-root user > > As for the container I'd suggest the previous fedora release's container > (i.e. f30 for f31). Do you think this should apply to all release-blocking installs, or should it be specific to e.g. release-blocking cloud images? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
> I don't know the formal process for proposal but here is a shot at a bare > minimum > start for trying to add containers to the existing release criteria. There is at least one deliverable that delivers podman in the image (Silverblue). Silverblue isn't release blocking. I don't know if there are others that do ship podman and are release blocking. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Proposing new release criteria
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1]. New section for Containers and Container tools: - A Fedora system can install the podman container runtime - The podman container runtime can pull/run a container from Fedora's registry as root - The podman container runtime can pull/run a container from Fedora's registry as a non-root user As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31). [1] https://bugzilla.redhat.com/show_bug.cgi?id=1737471#c22 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Fedora rawhide compose report: 20190829.n.0 changes
OLD: Fedora-Rawhide-20190828.n.0 NEW: Fedora-Rawhide-20190829.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 23 Dropped packages:24 Upgraded packages: 91 Downgraded packages: 0 Size of added packages: 209.44 MiB Size of dropped packages:11.72 MiB Size of upgraded packages: 5.08 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -53.62 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20190829.n.0.iso Image: SoaS raw-xz armhfp Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20190829.n.0-sda.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: R-gargle-0.3.1-1.fc32 Summary: Utilities for Working with Google APIs RPMs:R-gargle Size:284.75 KiB Package: R-lifecycle-0.1.0-1.fc32 Summary: Manage the Life Cycle of your Package Functions RPMs:R-lifecycle Size:89.54 KiB Package: gnome-python2-2.28.1-27.fc32 Summary: PyGNOME Python extension module RPMs:gnome-python2 gnome-python2-bonobo gnome-python2-canvas gnome-python2-devel gnome-python2-gconf gnome-python2-gnome gnome-python2-gnomevfs Size:2.16 MiB Package: gnome-python2-desktop-2.32.0-38.fc32 Summary: The sources for additional PyGNOME Python extension modules RPMs:gnome-python2-desktop gnome-python2-gnomekeyring gnome-python2-libwnck gnome-python2-rsvg Size:591.76 KiB Package: gtksourceview2-2.11.2-30.fc32 Summary: A library for viewing source files RPMs:gtksourceview2 gtksourceview2-devel Size:4.62 MiB Package: jolokia-jvm-agent-1.6.2-1.fc32 Summary: Jolokia JVM Agent RPMs:jolokia-jvm-agent Size:421.11 KiB Package: mingw-fribidi-1.0.5-1.fc32 Summary: MinGW Windows fribidi library RPMs:mingw32-fribidi mingw32-fribidi-static mingw64-fribidi mingw64-fribidi-static Size:197.76 KiB Package: mingw-qt5-qtwebchannel-5.12.4-1.fc32 Summary: Qt5 for Windows - QtWebChannel component RPMs:mingw32-qt5-qtwebchannel mingw64-qt5-qtwebchannel Size:201.95 KiB Package: nodejs-dateformat-3.0.3-5.fc32 Summary: Steven Levithan's excellent dateFormat() function for Node.js RPMs:nodejs-dateformat Size:13.79 KiB Package: nodejs-grunt-contrib-nodeunit-2.0.0-1.fc32 Summary: Run Nodeunit unit tests with grunt RPMs:nodejs-grunt-contrib-nodeunit Size:15.50 KiB Package: nodeunit-0.13.0-1.fc32 Summary: Easy asynchronous unit testing framework for Node.js RPMs:nodeunit Size:47.95 KiB Package: prometheus-jmx-exporter-0.12.0-1.fc32 Summary: Prometheus JMX Exporter RPMs:prometheus-jmx-exporter Size:438.07 KiB Package: prometheus-simpleclient-java-0.6.0-1.fc32 Summary: Prometheus JVM Client RPMs:prometheus-simpleclient-java Size:96.14 KiB Package: python-aexpect-1.5.1-5.module_f32+6098+36e6978f Summary: A python library to control interactive applications RPMs:python3-aexpect Size:51.09 KiB Package: python-avocado-71.0-1.module_f32+6098+36e6978f Summary: Framework with tools and libraries for Automated Testing RPMs:python-avocado-bash python-avocado-common python-avocado-examples python3-avocado python3-avocado-plugins-glib python3-avocado-plugins-golang python3-avocado-plugins-loader-yaml python3-avocado-plugins-output-html python3-avocado-plugins-result-upload python3-avocado-plugins-resultsdb python3-avocado-plugins-varianter-cit python3-avocado-plugins-varianter-pict python3-avocado-plugins-varianter-yaml-to-mux Size:771.50 KiB Package: python-ifcfg-0.18-1.fc32 Summary: Python cross-platform network interface discovery (ifconfig/ipconfig/ip) RPMs:python3-ifcfg Size:22.85 KiB Package: python-tw2-core-2.2.6-2.fc32 Summary: Web widget creation toolkit based on TurboGears widgets RPMs:python2-tw2-core python3-tw2-core Size:239.03 KiB Package: python27-2.7.16-8.fc32 Summary: Version 2.7 of the Python interpreter RPMs:python27 Size:64.55 MiB Package: python37-3.7.4-5.fc32 Summary: Version 3.7 of the Python interpreter RPMs:python37 Size:99.94 MiB Package: qd-2.3.22-1.fc32 Summary: Double-Double and Quad-Double Arithmetic RPMs:qd qd-devel Size:2.38 MiB Package: rubygem-sassc-2.2.0-1.fc32 Summary: Use libsass with Ruby! RPMs:rubygem-sassc rubygem-sassc-doc Size:533.18 KiB Package: swig-4.0.1-1.module_f32+6102+7b5a9978 Summary: Connects C/C++/Objective C to some high-level programming languages RPMs:ccache-swig swig swig-doc swig-gdb Size:12.92 MiB Package: xtl-0.6.5-1.fc32 Summary: QuantStack tools library RPMs:xtl-devel xtl-doc Size:18.94 MiB = DROPPED PACKAGES = Package: ailurus-10.10.3-19.fc31 Summary: A simple application installer and GNOME tweaker RPMs:ailurus Size:1.80 MiB Package: bleachbit-2.2-2.fc31 Summary: Python utility to free disk space and improve privacy RPMs:bleachbit Size:532.58 KiB Package: cherrytree-0.38.5-5.fc30 Su
Fedora-Rawhide-20190829.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 9 of 45 required tests failed, 6 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 30/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190828.n.0): ID: 438214 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/438214 Old failures (same test failed in Fedora-Rawhide-20190828.n.0): ID: 438149 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/438149 ID: 438150 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/438150 ID: 438166 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/438166 ID: 438167 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/438167 ID: 438170 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/438170 ID: 438171 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/438171 ID: 438172 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/438172 ID: 438173 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/438173 ID: 438174 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/438174 ID: 438181 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/438181 ID: 438183 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/438183 ID: 438184 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/438184 ID: 438185 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/438185 ID: 438187 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/438187 ID: 438216 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/438216 ID: 438218 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/438218 ID: 438220 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/438220 ID: 438278 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/438278 ID: 438280 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/438280 ID: 438281 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/438281 ID: 438283 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/438283 ID: 438284 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/438284 ID: 438285 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/438285 ID: 438287 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/438287 ID: 438288 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/438288 ID: 438289 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/438289 ID: 438292 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/438292 ID: 438293 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/438293 ID: 438294 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/438294 ID: 438299 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/438299 Soft failed openQA tests: 1/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20190828.n.0): ID: 438282 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/438282 Passed openQA tests: 101/152 (x86_64) New passes (same test not passed in Fedora-Rawhide-20190828.n.0): ID: 438209 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/438209 Skipped gating openQA tests: 4/152 (x86_64) Old skipped gating tests (s
two observations re: installing on dell precision tower 5810
over last couple days, several installations of pre-release fedora
images 201908{26,28,29} on this dell tower have produced the following
two symptoms.
first, this is a dual HD system and, when selecting the disk layout,
i would select both HDs, then select "I would like to make additional
space available," after which, on a number of occasions and almost
immediately, the install would hang and the screen would go blank. i
would not even get the chance to click "Done", the hang (if it
happened) invariably occurred within a second of clicking on the "I
would like to make additional space available" button. this happened a
number of times at precisely that point.
and, second, i downloaded and tried intalling the 0828 and 0829
ISOs and, while the installation seemed to go fine, when i rebooted, i
invariably got, very quickly, an unhappy looking terminal and:
Oh no! Something has gone wrong
A problem has occurred ...
rebooting made no difference -- the 28 and 29 images invariably failed
this way. going back to 0826 worked fine, so i'll stick with that for
now.
rday
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
