Re: Release criteria proposal: first boot experience
On Monday, September 7, 2020 7:25:49 AM MST Martin Kolman wrote: > On Tue, 2020-09-01 at 19:15 -0700, John M. Harris Jr wrote: > > > On Tuesday, September 1, 2020 1:22:26 PM MST Michael Catanzaro wrote: > > > > > Hi, > > > > > > We currently have a bug where the Online Accounts page in initial setup > > > > > > is nonfunctional. [1] This doesn't violate any current release > > > criterion, but surely we don't want to release with a broken initial > > > setup experience. So let's add a new requirement for that. How about > > > something like: > > > > > > "If an initial setup utility is run or intended to be run after the > > > first boot of the installed system, then it must start successfully and > > > > > > each page or panel of the initial setup utility should withstand a > > > basic functionality test." > > > > > > OK that's pretty basic, but it gets the point across. I think this can > > > be a final requirement, not necessarily important enough to be a beta > > > requirement. Bikeshed away! > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476 > > > > > > I would like to report a bug with the first boot experience: > > > > Upon installing a new GNOME system, I'm accosted with a dialog asking me > > questions about the system I just finished configuring in Anaconda. Is > > there something in Anaconda I'm missing to disable this behavior, or do > > I have to write my own kickstart to fix that? > > You can use the "fistboot --disable" command if you are installing via > kickstart: > https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#firstboot > That should disable all post installation setup tools (Initial Setup, Gnome > Initial Setup). I'm aware, I use kickstarts for the RHEL systems I deploy at work, but was hoping there'd be some option in the GUI for the graphical variants. It gets very annoying very quickly. ;) Thank you. -- John M. Harris, Jr. ___ 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: BTRFS, relatime vs. noatime
On Mon, Sep 7, 2020 at 6:30 AM Kamil Paral wrote: > > On Sun, Sep 6, 2020 at 1:37 AM Chris Murphy wrote: >> >> But if you've got a snapshot once per day, times ten days, and this kind of >> aggressive search function touching every file? Maybe an extra 1-2G of >> metadata being pinned > > > I don't follow. If you have one master copy and 10 snapshots, and you change > the metadata on the master copy, why would it generate more metadata (than > when having a single snapshot)? All those snapshots can share the same > metadata block (provided the file wasn't changed in the meantime) and just > the master copy would get a new metadata block. So it should be the same > amount of newly written blocks, regardless of how many snapshots you have. > What am I missing? Take the case of no snapshots, and also I'll just use "blocks" to refer to both metadata and data extents. The normal "modify something" pattern for copy-on-write is to write updated blocks into free space. It's never an overwrite. Even deleting a file requires some free space to write blocks indicating the file's deletion. Only once the new blocks are committed to stable media, are stale blocks deallocated (turned into free space). The resulting write pattern is: write changes into free space -> free space is reduced -> delay -> remove references to the stale blocks -> free space increases. If it's just atime updates happening, the net change in used space is zero. Now, let's snapshot. The effect of a snapshot on a copy-on-write file system is that the "stale" blocks are preserved. They aren't deallocated. This is why Btrfs snapshots are cheap. The snapshot effectively prevents the deallocation and clean up steps. Since there's no deallocation step, free space does not go up. The net change in used space goes up upon metadata updates following the snapshot. If I take no further snapshots, this is just a one time hit. Subsequent changes resume the normal pattern: write new->delay->deallocate stale = no net change. But upon snapshotting again, I pin that subvolume's state at that moment in time. -- 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
License correction for python-glad: MIT -> MIT and ASL 2.0
Hi, Upstream has clarified their license as they embed some Knronos/EGL specifications under a different license. Thus, the package's license has changed from MIT to MIT and ASL 2.0. -- Elliott ___ 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-20200907.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: 12/181 (x86_64) New failures (same test not failed in Fedora-Rawhide-20200906.n.0): ID: 657056 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/657056 ID: 657061 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/657061 ID: 657072 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/657072 ID: 657142 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/657142 ID: 657204 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/657204 Old failures (same test failed in Fedora-Rawhide-20200906.n.0): ID: 657074 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/657074 ID: 657101 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/657101 ID: 657109 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/657109 ID: 657130 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/657130 ID: 657135 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/657135 ID: 657170 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/657170 ID: 657197 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/657197 Soft failed openQA tests: 11/181 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20200906.n.0): ID: 657026 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/657026 ID: 657045 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/657045 ID: 657085 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/657085 ID: 657105 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/657105 ID: 657108 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/657108 ID: 657122 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/657122 ID: 657144 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/657144 ID: 657151 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/657151 ID: 657152 Test: x86_64 universal upgrade_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/657152 ID: 657156 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/657156 ID: 657178 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/657178 Passed openQA tests: 158/181 (x86_64) Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.93 to 1.14 Previous test data: https://openqa.fedoraproject.org/tests/656406#downloads Current test data: https://openqa.fedoraproject.org/tests/657069#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 31 MiB to 41 MiB System load changed from 0.65 to 0.48 Previous test data: https://openqa.fedoraproject.org/tests/656408#downloads Current test data: https://openqa.fedoraproject.org/tests/657071#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.74 to 0.95 Previous test data: https://openqa.fedoraproject.org/tests/656426#downloads Current test data: https://openqa.fedoraproject.org/tests/657089#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 19 MiB to 17 MiB System load changed from 0.31 to 0.47 Previous test data: https://openqa.fedoraproject.org/tests/656442#downloads Current test data: https://openqa.fedoraproject.org/tests/657105#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Used swap changed from 24 MiB to 20 MiB System load changed from 0.24 to 0.37 Previous test data: https://openqa.fedoraproject.org/tests/656445#downloads Current test data: https://openqa.fedoraproject.org/tests/657108#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___
Re: Btrfs by default status updates, 2020-09-07
On Mon, Sep 07, 2020 at 12:34:05PM -0600, Chris Murphy wrote: > + Communication: repurposing the Fedora Btrfs wiki as a landing page > is a work-in-progress > https://fedoraproject.org/wiki/Btrfs I prefer end-user documentation to not be in the wiki, because it's an easy click away to a lot of not-intended-for-end-users drafts, out-of-date and partial information, user pages, etc. My recommendation is to put this in the quick-docs https://docs.fedoraproject.org/en-US/quick-docs/ and make that page be a redirect. -- Matthew Miller Fedora Project Leader ___ 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
Btrfs by default status updates, 2020-09-07
+ F33 Btrfs By Default Test Week has concluded Test results page https://testdays.fedorainfracloud.org/events/92 Perhaps the most significant issue discovered is something of an edge case. The installer has performance issues when it encounters a Btrfs file system with many snapshots (500+ in this case). Untested, but since the handling is the same, I'd expect a similar issue with many LVM thin snapshots. https://bugzilla.redhat.com/show_bug.cgi?id=1876162#c23 --- + Subset of test day: There are two new test cases of interest that will hopefully be turned into Quick Docs: QA:Testcase partitioning custom btrfs preserve home https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home Draft: dual boot Fedoras - is a variation on the above test case. This is mostly leveraging BootLoaderSpec. The Btrfs part is incidental. But by using separate subvolumes for the different system roots for each Fedora, we're able to share a single Btrfs file system for much better space utilization. A future feature might be to dedup them. https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs --- + Documentation: preliminary install-guide updates https://pagure.io/fedora-docs/install-guide/pull-request/55 https://pagure.io/fedora-docs/install-guide/pull-request/56 --- + Communication: repurposing the Fedora Btrfs wiki as a landing page is a work-in-progress https://fedoraproject.org/wiki/Btrfs --- + devel@ discussion on possibly defaulting to noatime https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QXOM3QILEOYQ5CBSBZ5GMO5ZWQHHYZI7/#QXOM3QILEOYQ5CBSBZ5GMO5ZWQHHYZI7 -- 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: Looking for new Python package maintainers
On Mon, 7 Sep 2020 at 07:44, Dhanesh B. Sabane wrote: > Hello folks! > > I've been away from all Fedora activities for quite some time and I > don't see a return anytime soon. There are 6 Python packages which are > maintained by me and I'd like to hand them over. Following is the list > of packages: > > https://src.fedoraproject.org/user/dhanesh95/projects > > Please let me know if anyone would like to take these up by replying to > this email. I'll orphan all the packages that don't attract a > maintainer till Sunday, 13th Sept 2020. > > Cheers! > > If there are no takers, I'd like to maintain the python-blindspinner package. I see there is some room to bring in its "click" dependencies. ___ 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: Release criteria proposal: first boot experience
On Mon, Sep 7, 2020 at 2:24 AM Kamil Paral wrote: > > On Fri, Sep 4, 2020 at 8:17 PM Adam Williamson > wrote: >> >> On Fri, 2020-09-04 at 12:12 -0500, Michael Catanzaro wrote: >> > On Wed, Sep 2, 2020 at 12:57 pm, Kamil Paral wrote: >> > > Overall I find the criterion reasonable and useful and I'm +1 to >> > > incorporating it. Its current phrasing seems fine to me. >> > >> > So how does the process of adding the new criterion work? I guess we >> > should leave the weekend for additional comment, in case anybody wants >> > to suggest improvements, but it'd be nice to get this incorporated into >> > the release criteria and repropose the gnome-initial-setup bug. >> >> To be honest it's something we've never had the roundtuits to write up >> in a nice clean policy. The convention is basically: once a draft has >> been up for a while (say, a week or two, depending on urgency) without >> significant objections, you just go ahead and add it to the wiki. i.e. >> it's a fuzzy consensus system. :) > > > Yes, but I find it concerning that I was the only one who provided feedback > to this proposal. It might have been partially caused by the fact that it > wasn't sent to the test list. I urge everyone who has some opinion on this to > provide it, at least in the form of a thumbs up. Thanks. :thumbsup: -- 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: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)
Hello Kamil, > Bohdan, could you build the same image in several configurations (the most likely candidates) and share them with us? (We can host them in our QA fedorapeople space, if needed). That would allow interested parties to test and benchmark the experience themselves. I'll provide ISO images for testing at some point. One part of this change (https://pagure.io/pungi-fedora/pull-request/871#request_diff) was briefly included in the Rawhide compose for testing. This resulted in reduction of the DVD and BOOT.iso size by approximately ~24MiB without changing the compression parameters. The compose is available at the URI [1]. But due to the problem identified in anaconda's dracut module, the images were unbootable. I proposed a fix to the problem in https://github.com/rhinstaller/anaconda/pull/2820. [1] https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200828.n.0/compose/Server/x86_64/iso/ On 01/09/2020 14:13, Kamil Paral wrote: On Fri, Aug 28, 2020 at 12:55 AM Michel Alexandre Salim mailto:mic...@michel-slm.name>> wrote: On Thu, 2020-08-27 at 11:13 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/OptimizeSquashFS > > == Summary == > Improve compression ratio of SquashFS filesystem on the installation > media. > ... > > Based on the results above, I'd suggest selecting the following > ''optimal configuration'': XZ algorithm, with block size of 1MiB and > without BCJ filter (plain xz -b 1M, without -Xbcj x86). > On the right, you can see the impact of the compression algorithms on > installation time. > Why XZ as opposed to, say, ZSTD? Bohdan's preference seems to be to make the images smaller. I'm in the opposite camp. I'd like to keep the images roughly the same size (or smaller, but just a bit smaller, not as small as possible) and hugely speed up the installation instead. Which means zstd in one of the configurations. Each image is downloaded just once, but installed 1+ times. And with automation and all the CI work which Fedora and Red Hat invests a lot of effort into, it can be a hundred installations from a single image (without being bound to slow USB stick transfer speeds, as in the proposal). Of course, I'm biased. Bohdan, could you build the same image in several configurations (the most likely candidates) and share them with us? (We can host them in our QA fedorapeople space, if needed). That would allow interested parties to test and benchmark the experience themselves. ___ 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 -- Bohdan Khomutskyi RHEL Compose release engineer EXD Software production Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-33-20200907.0 compose check report
No missing expected images. Failed openQA tests: 1/16 (x86_64) New failures (same test not failed in Fedora-IoT-33-20200906.0): ID: 657523 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/657523 Passed openQA tests: 15/16 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.08 to 0.38 Previous test data: https://openqa.fedoraproject.org/tests/656724#downloads Current test data: https://openqa.fedoraproject.org/tests/657524#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Blocker Review discussion tickets -- now available
Hello everyone, I'd like to announce a new project of the QA team and an extension of the BlockerBugs App [1]. The blocker and freeze exception proposals can now not only be discussed during regular blocker review meetings [2], but also at any time through discussion tickets hosted on Pagure [3]. So even if you don't have time to participate in the meeting, you can still participate and vote in those discussion tickets. This will be mostly interesting to people who participated in blocker review meetings in the past, but we hope we can attract new participants this way. It is also very useful for package maintainers and developers, because they can now easily provide feedback regarding a proposed blocker or a freeze exception without attending a meeting at a particular time or diluting a technical discussion in Bugzilla. To participate, open the BlockerBugs App for a particular milestone (e.g. F33 Beta [4]) and you'll see "Vote!" and "Discuss" links for proposed/accepted blockers and freeze exceptions. Follow the links to see tickets where you can express your opinion (which should ideally reflect our release criteria [5]). You can vote according to the guide present at [3], please read it carefully. A bot is following each ticket, updating the voting summary, and accepting certain commands. Watching the Pagure repo [3] also gives you the option to get notified about every new proposed blocker/freeze exception. We've been using these discussions for a week or two now (I apologize for a late announcement) and so far our existing practice seems to be to vote for proposals throughout the week using these discussion tickets, close those which we can easily get enough votes and agree on, and discuss the remainder during the next blocker review meeting. So the regular blocker review meeting hasn't been replaced, but we use the discussion tickets to cut down on the meeting length. We're still trying to figure out the best approach to take here, so nothing is set in stone. The voting functionality itself is also still in development, we'll try to provide new features and improve the experience based on your feedback. I'll be happy to answer questions, if there are any. Thanks, Kamil Fedora QA PS: Development credits go to Lukas Brabec, Frantisek Zatloukal, Tim Flink, Josef Skladanka and Adam Williamson. [1] https://qa.fedoraproject.org/blockerbugs/ [2] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [3] https://pagure.io/fedora-qa/blocker-review [4] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist [5] https://fedoraproject.org/wiki/Fedora_Release_Criteria ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-33-20200907.n.0 compose check report
No missing expected images. Failed openQA tests: 10/181 (x86_64) New failures (same test not failed in Fedora-33-20200906.n.0): ID: 657220 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/657220 ID: 657266 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/657266 ID: 657302 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/657302 Old failures (same test failed in Fedora-33-20200906.n.0): ID: 657294 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/657294 ID: 657296 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/657296 ID: 657325 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/657325 ID: 657330 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/657330 ID: 657351 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/657351 ID: 657373 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/657373 ID: 657392 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/657392 Soft failed openQA tests: 9/181 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-33-20200906.n.0): ID: 657221 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/657221 ID: 657240 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/657240 ID: 657267 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/657267 ID: 657280 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/657280 ID: 657300 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/657300 ID: 657303 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/657303 ID: 657317 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/657317 ID: 657329 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/657329 ID: 657354 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/657354 Passed openQA tests: 162/181 (x86_64) New passes (same test not passed in Fedora-33-20200906.n.0): ID: 657285 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/657285 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 1.22 to 0.57 Previous test data: https://openqa.fedoraproject.org/tests/656587#downloads Current test data: https://openqa.fedoraproject.org/tests/657264#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used swap changed from 14 MiB to 10 MiB System load changed from 1.33 to 1.65 Previous test data: https://openqa.fedoraproject.org/tests/656606#downloads Current test data: https://openqa.fedoraproject.org/tests/657283#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Average CPU usage changed from 22.60952381 to 10.47142857 Previous test data: https://openqa.fedoraproject.org/tests/656607#downloads Current test data: https://openqa.fedoraproject.org/tests/657284#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 20 MiB to 25 MiB Previous test data: https://openqa.fedoraproject.org/tests/656623#downloads Current test data: https://openqa.fedoraproject.org/tests/657300#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Used swap changed from 30 MiB to 25 MiB System load changed from 0.20 to 0.31 Previous test data: https://openqa.fedoraproject.org/tests/656626#downloads Current test data: https://openqa.fedoraproject.org/tests/657303#downloads Installed system changes in test x86_64 universal install_package_set_kde: Used swap changed from 1 MiB to 8 MiB System load changed from 1.35 to 1.21 Previous test data: https://openqa.fedoraproject.org/tests/656667#downloads Current test data: https://openqa.fedoraproject.org/tests/657344#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-condu
Re: Release criteria proposal: first boot experience
On Tue, 2020-09-01 at 19:15 -0700, John M. Harris Jr wrote: > On Tuesday, September 1, 2020 1:22:26 PM MST Michael Catanzaro wrote: > > Hi, > > > > We currently have a bug where the Online Accounts page in initial setup > > is nonfunctional. [1] This doesn't violate any current release > > criterion, but surely we don't want to release with a broken initial > > setup experience. So let's add a new requirement for that. How about > > something like: > > > > "If an initial setup utility is run or intended to be run after the > > first boot of the installed system, then it must start successfully and > > each page or panel of the initial setup utility should withstand a > > basic functionality test." > > > > OK that's pretty basic, but it gets the point across. I think this can > > be a final requirement, not necessarily important enough to be a beta > > requirement. Bikeshed away! > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476 > > I would like to report a bug with the first boot experience: > > Upon installing a new GNOME system, I'm accosted with a dialog asking me > questions about the system I just finished configuring in Anaconda. Is there > something in Anaconda I'm missing to disable this behavior, or do I have to > write my own kickstart to fix that? You can use the "fistboot --disable" command if you are installing via kickstart: https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#firstboot That should disable all post installation setup tools (Initial Setup, Gnome Initial Setup). > > -- > John M. Harris, Jr. > > ___ > 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
libcbor-0.7.0 SONAME change
Hi all, The new version of libcbor package will arrive soon and there are going to be some changes. SONAME change: "libcbor.so.0" to "libcbor.so.0.7" (More info: https://github.com/PJK/libcbor/issues/52) Rename cbor_ctrl_is_bool to cbor_get_bool (More info: https://github.com/PJK/libcbor/issues/63) Attila Lakatos ___ 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-IoT-34-20200907.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 2/16 (x86_64) ID: 657453 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/657453 ID: 657459 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/657459 Passed openQA tests: 14/16 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 compose report: 20200907.n.0 changes
OLD: Fedora-33-20200906.n.0 NEW: Fedora-33-20200907.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: BTRFS, relatime vs. noatime
On Mon, Sep 7, 2020 at 8:30 AM Kamil Paral wrote: > > On Sun, Sep 6, 2020 at 1:37 AM Chris Murphy wrote: >> >> But if you've got a snapshot once per day, times ten days, and this kind of >> aggressive search function touching every file? Maybe an extra 1-2G of >> metadata being pinned > > > I don't follow. If you have one master copy and 10 snapshots, and you change > the metadata on the master copy, why would it generate more metadata (than > when having a single snapshot)? All those snapshots can share the same > metadata block (provided the file wasn't changed in the meantime) and just > the master copy would get a new metadata block. So it should be the same > amount of newly written blocks, regardless of how many snapshots you have. > What am I missing? When you have snapshots, you initially share all the same blocks. However, as you continue to make changes, fewer of the blocks are shared as new blocks are allocated for new changes. This is also true for metadata, except that this situation results in the filesystem making new instances of the metadata for most of its files. However, because you have snapshots, the old instances cannot be deleted either. Thus, you wind up with essentially a new copy of the filesystem metadata. This is amplified as you take more snapshots. This is the *expensive* part of snapshots and the part that people don't necessarily realize: when you take a snapshot, you're asking for the preservation of the entire filesystem tree, with all its data. If you take a snapshot, then change the atimes of all the files, take a snapshot again, then change the atimes again, you wind up having two whole unshared instances of the filesystem snapshotted. It's essentially the worst case scenario for filesystem metadata. Of course, this is cheap to *make*, but expensive to *keep* as you run out of space due to just having so many unique copies of filesystem metadata. This is why it's often recommended that atimes are switched off on parts of the filesystem you wish to aggressively snapshot. For example, most of the time you don't really care about atimes for /usr and /etc, so you can turn atimes off for that, while leaving it on for /var and /home. Now, we are not setting up snapshotting automatically in Fedora like openSUSE does, so there's not as much pressure to deal with it now. But if we make a straightforward way for people to set up snapshotting, then part of that strategy needs to include dealing with that problem. -- 真実はいつも一つ！/ 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
Re: BTRFS, relatime vs. noatime
On Sun, Sep 6, 2020 at 1:37 AM Chris Murphy wrote: > But if you've got a snapshot once per day, times ten days, and this kind > of aggressive search function touching every file? Maybe an extra 1-2G of > metadata being pinned > I don't follow. If you have one master copy and 10 snapshots, and you change the metadata on the master copy, why would it generate more metadata (than when having a single snapshot)? All those snapshots can share the same metadata block (provided the file wasn't changed in the meantime) and just the master copy would get a new metadata block. So it should be the same amount of newly written blocks, regardless of how many snapshots you have. What am I missing? ___ 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: Looking for new Python package maintainers
Hey Pruthvi, > I am looking for packages to maintain and this would help a lot. > Do let me know the package that you'd like to maintain and I'll add you as a co-maintainer for it. Have a good one! Cheers! Dhanesh Sabane ___ 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: Looking for new Python package maintainers
Hello Lumir, > I'd like to maintain: > > python-first > python-pipdeptree > python-pipreqs > python-yarg > > These are dependencies of pipenv we (@python-sig) maintain so please add > me as an admin and this group as co-maintainer. > I've added you as admin and @python-sig as committer for the requested packages. Thank you for taking ownership of these packages! :) Have a good one! Cheers! Dhanesh Sabane ___ 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: noarch packages only for some architecture composes
On Mon, Sep 7, 2020 at 1:02 PM Florian Weimer wrote: > > Is it possible to include a noarch package only in some of the composes? > > The background is that I added glibc-headers-x86.noarch to deal with a > conflict between inconsistent composes (glibc-headers.i686 was sometimes > in the x86_64 compose, sometimes it was not). glibc-headers-x86.noarch > is always in the compose, and thus avoids the issue. But an > unanticipated side effect is that glibc-headers-x86 (and > glibc-headers-s390) show up across all architectures. I'm concerned > that this is potentially confusing. I don't think this is possible, and since I consider this to be a bug, I reported this a while ago: koji#1843: noarch packages getting copied to repos explicitly excluded in ExclusiveArch https://pagure.io/koji/issue/1843 Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
noarch packages only for some architecture composes
Is it possible to include a noarch package only in some of the composes? The background is that I added glibc-headers-x86.noarch to deal with a conflict between inconsistent composes (glibc-headers.i686 was sometimes in the x86_64 compose, sometimes it was not). glibc-headers-x86.noarch is always in the compose, and thus avoids the issue. But an unanticipated side effect is that glibc-headers-x86 (and glibc-headers-s390) show up across all architectures. I'm concerned that this is potentially confusing. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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: 20200907.n.0 changes
OLD: Fedora-Rawhide-20200906.n.0 NEW: Fedora-Rawhide-20200907.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 51 Downgraded packages: 0 Size of added packages: 64.95 KiB Size of dropped packages:0 B Size of upgraded packages: 3.17 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 16.31 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20200907.n.0-sda.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: rust-netlink-sys-0.4.0-1.fc34 Summary: Netlink sockets, with optional integration with mio and tokio RPMs:rust-netlink-sys+default-devel rust-netlink-sys+futures-devel rust-netlink-sys+mio-devel rust-netlink-sys+mio_socket-devel rust-netlink-sys+tokio-devel rust-netlink-sys+tokio_socket-devel rust-netlink-sys-devel Size:64.95 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Lmod-8.4.4-1.fc34 Old package: Lmod-8.4.3-1.fc34 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.06 MiB Size change: 447 B Changelog: * Sun Sep 06 2020 Orion Poplawski - 8.4.4-1 - Update to 8.4.4 Package: at-spi2-core-2.37.92-1.fc34 Old package: at-spi2-core-2.37.90-1.fc34 Summary: Protocol definitions and daemon for D-Bus at-spi RPMs: at-spi2-core at-spi2-core-devel Size: 1.79 MiB Size change: -746 B Changelog: * Sun Sep 06 2020 Kalev Lember - 2.37.92-1 - Update to 2.37.92 Package: bluez-5.55-1.fc34 Old package: bluez-5.54-4.fc33 Summary: Bluetooth utilities RPMs: bluez bluez-cups bluez-hid2hci bluez-libs bluez-libs-devel bluez-mesh bluez-obexd Size: 10.27 MiB Size change: 532.24 KiB Changelog: * Sun Sep 06 2020 Peter Robinson - 5.55-1 - Update to 5.55 Package: cawbird-1.1.0-3.fc34 Old package: cawbird-1.1.0-3.fc33 Summary: Fork of the Corebird GTK Twitter client that continues to work with Twitter RPMs: cawbird Size: 2.80 MiB Size change: 3.82 KiB Package: cglib-3.2.9-8.fc34 Old package: cglib-3.2.9-7.fc33 Summary: Code Generation Library for Java RPMs: cglib cglib-javadoc Size: 789.06 KiB Size change: -32 B Changelog: * Sun Aug 30 2020 Fabio Valentini - 3.2.9-8 - Remove unnecessary dependency on parent POM. Package: deluge-2.0.3-12.fc34 Old package: deluge-2.0.3-11.fc34 Summary: A GTK+ BitTorrent client with support for DHT, UPnP, and PEX RPMs: deluge deluge-common deluge-console deluge-daemon deluge-gtk deluge-images deluge-web Size: 2.37 MiB Size change: 10.63 KiB Changelog: * Tue Aug 18 2020 Michael Cronenworth - 2.0.3-12 - Restructure Requires - Add patch for GTK comparing None types (RHBZ#1812790) Package: dummy-test-package-crested-0-1366.fc34 Old package: dummy-test-package-crested-0-1352.fc34 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 90.38 KiB Size change: 839 B Changelog: * Sun Sep 06 2020 packagerbot - 0-1353 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1354 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1355 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1356 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1357 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1358 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1359 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1360 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1361 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1362 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1363 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1364 - rebuilt * Mon Sep 07 2020 packagerbot - 0-1365 - rebuilt * Mon Sep 07 2020 packagerbot - 0-1366 - rebuilt Package: dummy-test-package-gloster-0-1309.fc34 Old package: dummy-test-package-gloster-0-1301.fc34 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 86.93 KiB Size change: 489 B Changelog: * Sun Sep 06 2020 packagerbot - 0-1302 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1303 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1304 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1305 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1306 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1307 - rebuilt * Mon Sep 07 2020 packagerbot - 0-1308 - rebuilt * Mon Sep 07 2020 packagerbot - 0-1309 - rebuilt Package: dummy-test-package-rubino-0-1366.fc34 Old package: dummy-test-package-rubino-0-1352.fc34 Summary: Dummy Test Package called Rubino RPMs: dummy-test-package-rubino Size: 90.44 KiB Size change: 841 B Changelog: * Sun Sep 06 2020 packagerbot - 0-1353 - rebuilt * Sun Sep 06 2020 packagerbot - 0-1354 - rebuilt * Sun
Fedora-Cloud-31-20200907.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20200907.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20200905.0): ID: 656801 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/656801 Passed openQA tests: 6/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Release criteria proposal: first boot experience
On Fri, Sep 4, 2020 at 8:17 PM Adam Williamson wrote: > On Fri, 2020-09-04 at 12:12 -0500, Michael Catanzaro wrote: > > On Wed, Sep 2, 2020 at 12:57 pm, Kamil Paral wrote: > > > Overall I find the criterion reasonable and useful and I'm +1 to > > > incorporating it. Its current phrasing seems fine to me. > > > > So how does the process of adding the new criterion work? I guess we > > should leave the weekend for additional comment, in case anybody wants > > to suggest improvements, but it'd be nice to get this incorporated into > > the release criteria and repropose the gnome-initial-setup bug. > > To be honest it's something we've never had the roundtuits to write up > in a nice clean policy. The convention is basically: once a draft has > been up for a while (say, a week or two, depending on urgency) without > significant objections, you just go ahead and add it to the wiki. i.e. > it's a fuzzy consensus system. :) > Yes, but I find it concerning that I was the only one who provided feedback to this proposal. It might have been partially caused by the fact that it wasn't sent to the test list. I urge everyone who has some opinion on this to provide it, at least in the form of a thumbs up. Thanks. ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-09-07.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainers Status Change apache-commons-dbcp mizdebsk, orphan 3 weeks ago container-exception-loggerabrt-sig, ekulik, mmarusak, 2 weeks ago msuchy, orphan dbus-java orphan 4 weeks ago emacs-magit orphan, petersen 0 weeks ago fedora-icon-theme orphan 0 weeks ago freight orphan 0 weeks ago fst orphan 4 weeks ago geronimo-parent-poms jjelen, mizdebsk, orphan 2 weeks ago golang-github-mholt- orphan 1 weeks ago certmagic-0.9 joda-time mizdebsk, orphan 3 weeks ago js-jquery-iframe-transportorphan 4 weeks ago js-jquery-knoborphan 4 weeks ago js-jquery-qrcode orphan 4 weeks ago js-tag-it orphan 4 weeks ago jvnet-parent mizdebsk, orphan 2 weeks ago libmatthew-java orphan 4 weeks ago liquibase awood, orphan4 weeks ago man-pages-de orphan, romal4 weeks ago marble-widget orphan, rdieter 1 weeks ago mozilla-iot-gateway-addon-nodeorphan 4 weeks ago mozilla-iot-gateway-addon-orphan 4 weeks ago python nodejs-babel-code-frame orphan 0 weeks ago nodejs-base orphan 0 weeks ago nodejs-bcrypt nodejs-sig, orphan 0 weeks ago nodejs-body-parserorphan 0 weeks ago nodejs-bufferutil nodejs-sig, orphan 0 weeks ago nodejs-cache-base orphan 0 weeks ago nodejs-call-matcher orphan 0 weeks ago nodejs-core-util-is nodejs-sig, orphan 5 weeks ago nodejs-cross-spawnnodejs-sig, orphan 0 weeks ago nodejs-cross-spawn-async nodejs-sig, orphan 0 weeks ago nodejs-css-stringify nodejs-sig, orphan, patches 2 weeks ago nodejs-css-tree orphan 2 weeks ago nodejs-doctrine galileo, nodejs-sig, orphan, 0 weeks ago vjancik nodejs-duplexer nodejs-sig, orphan 5 weeks ago nodejs-duplexify nodejs-sig, orphan 5 weeks ago nodejs-end-of-stream nodejs-sig, orphan 5 weeks ago nodejs-espower-location- orphan 2 weeks ago detector nodejs-esrecurse nodejs-sig, orphan 0 weeks ago nodejs-faucet orphan 0 weeks ago nodejs-from nodejs-sig, orphan 5 weeks ago nodejs-fs-dot-notify orphan 0 weeks ago nodejs-gauge nodejs-sig, orphan 0 weeks ago nodejs-global-prefix nodejs-sig, orphan 0 weeks ago nodejs-grunt nodejs-sig, orphan, patches, 2 weeks ago piotrp nodejs-grunt-legacy-util nodejs-sig, orphan, patches, 0 weeks ago piotrp
Re: BZ + Firefox: browser freezes when choosing close reason?
Hi Till, please install firefox-x11 package and use Firefox X11 to test if it's caused by Wayland backend. Also please file a new bug at #BZ so it can be diagnosed more, i.e. test Mozilla binaries, disable extensions etc.. Thanks, Martin On 9/5/20 2:50 PM, Till Hofmann wrote: Hi all, I'm having a weird problem with Bugzilla: Whenever I want to close an issue and I click on the reason menu (the one that shows NOTABUG, NEXTRELEASE etc.), my browser freezes. Is anyone else seeing this issue? I've tried to search for similar bug reports, but searching for "bugzilla firefox bug status" obviously doesn't result in anything useful. I've seen this for a couple of weeks now. This is on Fedora 32 with Firefox 80.0.1. Kind regards, Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Martin Stransky Software Engineer / 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
