Re: libplacebo conflicts in f34 repo
Hello Misterx42 You will see there is a new update now on RPM fusion from "mpv 0.33.0-6.fc34" and this new build solves the dependency problem. best regards Geraldo geraldosimiao Em sex., 2 de abr. de 2021 às 15:18, misterx42--- via test < test@lists.fedoraproject.org> escreveu: > I'm not sure if this is supposed to go to the bug tracker, so I thought > I'll report it here first. > > libplacebo is currently being blocked from upgrading due to mpv's > dependency on the old version: > > Problem: package mpv-0.33.0-5.fc34.x86_64 requires > libplacebo.so.104()(64bit), but none of the providers can be installed > - cannot install both libplacebo-3.120.0-1.fc34.x86_64 and > libplacebo-3.104.0-1.fc34.x86_64 > - cannot install both libplacebo-3.104.0-1.fc34.x86_64 and > libplacebo-3.120.0-1.fc34.x86_64 > - cannot install the best update candidate for package > mpv-0.33.0-5.fc34.x86_64 > - cannot install the best update candidate for package > libplacebo-3.104.0-1.fc34.x86_64 > > This is my first time running a Beta version for Fedora, so I don't know > if these problems are expected and will be resolved automatically, thus I > haven't opened a bug yet - figured it's better to ask than to add more work > to people. > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-34-20210401.n.0 compose check report
No missing expected images. Failed openQA tests: 3/178 (x86_64), 6/127 (aarch64) New failures (same test not failed in Fedora-34-20210330.n.0): ID: 839705 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/839705 ID: 839766 Test: aarch64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/839766 ID: 839767 Test: aarch64 universal install_anaconda_text@uefi URL: https://openqa.fedoraproject.org/tests/839767 ID: 839774 Test: aarch64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/839774 ID: 839789 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/839789 ID: 839800 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/839800 Old failures (same test failed in Fedora-34-20210330.n.0): ID: 839581 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/839581 ID: 839682 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/839682 ID: 839757 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/839757 Soft failed openQA tests: 6/127 (aarch64), 4/178 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-34-20210330.n.0): ID: 839786 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/839786 Old soft failures (same test soft failed in Fedora-34-20210330.n.0): ID: 839504 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/839504 ID: 839545 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/839545 ID: 839591 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/839591 ID: 839597 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/839597 ID: 839610 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/839610 ID: 839635 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/839635 ID: 839650 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/839650 ID: 839672 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/839672 ID: 839731 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/839731 Passed openQA tests: 171/178 (x86_64), 115/127 (aarch64) New passes (same test not passed in Fedora-34-20210330.n.0): ID: 839550 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/839550 ID: 839576 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/839576 ID: 839598 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/839598 ID: 839599 Test: aarch64 Minimal-raw_xz-raw.xz base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/839599 ID: 839600 Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/839600 ID: 839601 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/839601 ID: 839602 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/839602 ID: 839603 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/839603 ID: 839604 Test: aarch64 Minimal-raw_xz-raw.xz base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/839604 ID: 839617 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/839617 ID: 839620 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/839620 ID: 839621 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/839621 ID: 839626 Test: aarch64 Server-dvd-iso base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/839626 ID: 839633 Test: aarch64 Server-dvd-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/839633 ID: 839636 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/839636 ID: 839638 Test: aarch64 Server-dvd-iso base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/839638 ID: 839643 Test: aarch64
Re: [Proposal] The dual head set-up criterion
On Thu, 2021-04-01 at 23:36 -0600, Chris Murphy wrote: > On Thu, Apr 1, 2021 at 1:12 PM Ben Cotton wrote: > > > > On Tue, Mar 30, 2021 at 7:27 AM Lukas Ruzicka wrote: > > > > > > I would like to propose a new release covering criterion that was > > > suggested on the yesterday's Blocker Review Meeting. Please let me know, > > > what you think about it and perhaps suggest improvements. > > > > > > > I like the idea of dual monitors being a blocker in general, but as > > this thread shows, it gets complicated quickly. I think if we do this, > > it should be very narrowly scoped. The two main use cases we need to > > worry about are: > > > > 1. Laptop with an external monitor (and does it have to be directly > > attached, or would we block if a monitor attached via a docking > > station doesn't work?) > > 2. Desktop with a single video card that drives two monitors > > > > I suspect that this would cover most usage without getting too caught > > up in all of the possible hardware combinations, especially since one > > major video card manufacturer isn't the best at supporting Linux. > > > > I agree. Yeah, I think even the 'conservative' version is a bit too ambitious for a first movement towards blocking on this. I agree with Ben and Chris about restricting it to these most-common and most-important cases, and we might want to hedge it around a bit with reference to the relevant FAQ sections: https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F https://fedoraproject.org/wiki/Blocker_Bug_FAQ#Why_isn.27t_my_graphics_card_showstopper_bug_a_blocker.3F_I_can.27t_boot.21 I think personally I'd probably only be inclined to take a bug in this area as a blocker if it completely broke external output on a popular laptop line or family (e.g. XPS 13, Thinkpad X1), or broke things across a popular family or generation of desktop adapters... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Can outreachy pre interns open issue or Mentors must do it?
Dear community, Can Outreachy pre interns open issue or Mentors should do it? Kind Regards, Alisina ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: /boot on btrfs
On Fri, Apr 2, 2021 at 3:50 AM TheEvilSkeleton wrote: > > I tried using /boot on btrfs a couple of times some days ago, and it kept > failing each time until I used ext4. > > This is bad UX. If I need to "fiddle with enough" on a problem that wasn't > supposed to be a problem, it should be addressed. Yep. But also understand that the installer team, just like many teams, has fewer resources than the task list for features, bug fixes, and regular maintenance. Btrfs enhancements are simply a lower priority. Compression by default in Fedora 34, is actually a Fedora community supported feature. It's not officially supported by the Anaconda or Blivet teams (although they did provide quite a lot of advice that was crucial to making the feature ultimately work). Since Silverblue is not a release blocking edition or spin, some rough edged UX is permitted for non-default paths. /boot on Btrfs is one of them. I don't know if anyone knows exactly what the issue is, and thus what fix it needed, so that'd be the first step is look in rpm-ostree issues to see if this is already known, or in the Silverblue tracker. > By default, when using the automatic install process, /boot uses ext4 when it > should be using btrfs instead, and when using the custom partitioning tool, > it should allow me to use btrfs without it being a reason to failure. Yeah it's not that simple. Fedora depends on a feature "grub hidden menu" to provide flicker and menu free boots. GRUB pre-boot reads /boot/grub2/grubenv to know if the previous boot succeed or not, while resetting the variable in this file. GRUB is disallowed from writing to this file when it's on Btrfs, ZFS, md raid, or LUKS. Various issues need to be discussed in terms of the Boot Loader Interface and Boot Loader Specification. We need some kind of standardization, not just keep adding more things for the sake of doing them. And right now BLS and BLI are very UEFI and x86 centric, leaving out too many other platforms we care about. The specs need shoring up. And the bootloaders need to reflect the specs, and then there's installer and image builder work. This particular bug might have a simple fix, but you'd need to help the upstream projects find out exactly what's wrong. -- Chris Murphy ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
libplacebo conflicts in f34 repo
I'm not sure if this is supposed to go to the bug tracker, so I thought I'll report it here first. libplacebo is currently being blocked from upgrading due to mpv's dependency on the old version: Problem: package mpv-0.33.0-5.fc34.x86_64 requires libplacebo.so.104()(64bit), but none of the providers can be installed - cannot install both libplacebo-3.120.0-1.fc34.x86_64 and libplacebo-3.104.0-1.fc34.x86_64 - cannot install both libplacebo-3.104.0-1.fc34.x86_64 and libplacebo-3.120.0-1.fc34.x86_64 - cannot install the best update candidate for package mpv-0.33.0-5.fc34.x86_64 - cannot install the best update candidate for package libplacebo-3.104.0-1.fc34.x86_64 This is my first time running a Beta version for Fedora, so I don't know if these problems are expected and will be resolved automatically, thus I haven't opened a bug yet - figured it's better to ask than to add more work to people. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
libplacebo conflicts in f34 repo
I'm not sure if this is supposed to go to the bug tracker, so I thought I'll report it here first. libplacebo is currently being blocked from upgrading due to mpv's dependency on the old version: Problem: package mpv-0.33.0-5.fc34.x86_64 requires libplacebo.so.104()(64bit), but none of the providers can be installed - cannot install both libplacebo-3.120.0-1.fc34.x86_64 and libplacebo-3.104.0-1.fc34.x86_64 - cannot install both libplacebo-3.104.0-1.fc34.x86_64 and libplacebo-3.120.0-1.fc34.x86_64 - cannot install the best update candidate for package mpv-0.33.0-5.fc34.x86_64 - cannot install the best update candidate for package libplacebo-3.104.0-1.fc34.x86_64 This is my first time running a Beta version for Fedora, so I don't know if these problems are expected and will be resolved automatically, thus I haven't opened a bug yet - figured it's better to ask than to add more work to people. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: /boot on btrfs
On Fri, Apr 2, 2021 at 3:42 AM TheEvilSkeleton wrote: > > A couple of days ago I tried to manually install Fedora 34 Silverblue on UEFI > system and it kept failing when I was using /boot on btrfs. When I switched > to ext4, it installed flawlessly. I will try it soon on the ISO you linked > and will report back if this issue persists or not. Silverblue is a different story. It creates the BLS drop-in scripts differently than conventional Fedora's. It may not have the logic to handle /boot on Btrfs, or possibly more specifically it may not have the logic to handle /boot on a Btrfs subvolume which is how the installer lays out all Btrfs setups. -- Chris Murphy ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: /boot on btrfs
On Thu, Apr 1, 2021 at 11:18 AM Proprietary Chrome-chan < theevilskele...@fedoraproject.org> wrote: > Hi, > > `/boot` can be used on btrfs. However, Anaconda forces me to use ext4 in > that specific, when it shouldn't if you use btrfs. > > I'd like to request allowing `/boot` to be used on btrfs. > You've gotten plenty of responses on the HOW TO but I'm more curious about the WHY? :) Personally if I was going to modify the default install behavior it would be to make a decent size exFAT partition and combine /boot and /boot/EFI and use systemd-boot. It's a way simpler boot process than GRUB. I didn't know about it until I had trouble running Fedora on a Microsoft GO Tablet and grub just didn't know how to boot it. Thanks, Richard ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: /boot on btrfs
I tried using /boot on btrfs a couple of times some days ago, and it kept failing each time until I used ext4. This is bad UX. If I need to "fiddle with enough" on a problem that wasn't supposed to be a problem, it should be addressed. By default, when using the automatic install process, /boot uses ext4 when it should be using btrfs instead, and when using the custom partitioning tool, it should allow me to use btrfs without it being a reason to failure. On April 2, 2021 1:32:05 AM EDT, Chris Murphy wrote: >On Thu, Apr 1, 2021 at 10:18 AM Proprietary Chrome-chan > wrote: >> >> Hi, >> >> `/boot` can be used on btrfs. However, Anaconda forces me to use ext4 in >> that specific, when it shouldn't if you use btrfs. >> >> I'd like to request allowing `/boot` to be used on btrfs. > >You can do this in Custom partitioning, if you fiddle with it enough. >However... I recommend you create a 1-2G Btrfs boot outside of the >installer. The installer will let you assign it to the /boot mount >point without reformatting it. > >The reason is it's better to use the 'mkfs.btrfs --mixed' option for >file systems of this size. > >-- >Chris Murphy >___ >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 >Do not reply to spam on the list, report it: >https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: /boot on btrfs
A couple of days ago I tried to manually install Fedora 34 Silverblue on UEFI system and it kept failing when I was using /boot on btrfs. When I switched to ext4, it installed flawlessly. I will try it soon on the ISO you linked and will report back if this issue persists or not. On April 1, 2021 7:44:06 PM EDT, FUNG Chi Chuen Sampson wrote: >Anaconda do not complain about /boot partition using btrfs, as tested with >https://kojipkgs.fedoraproject.org/compose/branched/Fedora-34-20210401.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-34-20210401.n.0.iso > >Testing steps: > >1. Boot the USB >2. Choose Custom Storager >3. Remove All existing partitions >4. By using the default btrfs scheme, choose to create the default layout >5. Edit /boot, change type to btrfs >6. Result: >- /dev/sda1 - 1GB, btrfs >- /dev/sda2 - 180GB, btrfs >* subvol / >* subvol /home >(It is on a legacy BIOS system, so no EFI partition created.) >___ >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 >Do not reply to spam on the list, report it: >https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
