Re: Tenacity
On 2/8/23 9:30 PM, Reon Beon via devel wrote: wxGTK should have that... It should, and they fixed it, but the fix never made it to the 3.1.X series as far as I can tell. 3.2.1 in F37 at least builds, but for some reason liblibnyquist.so is missing. F38 / Rawhide has some lisp issue with the libnyquist stuff. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Tenacity
On 2/8/23 10:59 AM, Jason L Tibbitts III wrote: stan via devel writes: As they say in the BUILDING.md file, though, fedora lacks wxWidgets 3.1.5 or greater. That stops the configuration, cmake -G Ninja -S . -B build when it errors out. That's odd; as far as I can see, F36 has 3.1.5 and F37 has 3.2.1. - J< Both versions make it through the configure step for me, but a build with 3.1.5 will ultimately fail with "fatal error: wx/filedlgcustomize.h: No such file or directory", (upstream issue 22516[0]). [0] - https://github.com/wxWidgets/wxWidgets/issues/22516 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Tenacity
On 2/7/23 1:25 PM, Philip Rhoades via devel wrote: People, Has there been any discussion about getting a Tenacity RPM going for Fedora? - I would prefer that to having to use the AppImage version . . Thanks, Phil. I have a copr[0]. It has some issues and the current version is old. I have been working on updating to the latest beta from the new upstream location[1], but $DAY_JOB has been consuming a lot of my time. [0] - https://copr.fedorainfracloud.org/coprs/nielsenb/tenacity/ [1] - https://codeberg.org/tenacityteam/tenacity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenPrinting NEWS from Linux Plumbers 2022 AKA feel free to try driverless printing and printer applications in SNAPs
On 9/16/22 8:40 AM, Brandon Nielsen wrote: On 9/15/22 12:01 PM, Vitaly Zaitsev via devel wrote: On 15/09/2022 13:35, Zdenek Dohnal wrote: 1. install snapd No. Thanks. Please build regular RPMs. I maintain a copr[0]. Unfortunately a move and a new job have kept me from giving them as much love as I would like recently, but they at least give an idea of how things should work. Realize I forgot the reference, derp. [0] - https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenPrinting NEWS from Linux Plumbers 2022 AKA feel free to try driverless printing and printer applications in SNAPs
On 9/15/22 12:01 PM, Vitaly Zaitsev via devel wrote: On 15/09/2022 13:35, Zdenek Dohnal wrote: 1. install snapd No. Thanks. Please build regular RPMs. I maintain a copr[0]. Unfortunately a move and a new job have kept me from giving them as much love as I would like recently, but they at least give an idea of how things should work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Mumble 1.4 (Self-Contained Change proposal)
On 7/18/22 12:29 PM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Mumble1.4 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the Mumble voice chat application from 1.3 to 1.4. [Snip] * Enable the native PipeWire audio backend * Rename the Mumble server package from murmur to mumble-server, per upstream preference * Relocate Mumble server configuration file from /etc/murmur/murmur.ini to /etc/murmur.ini, per upstream preference [Snip] Excellent, glad to see the changes to follow upstream. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: News from printing world aka PWG May 2022 meetup
On 5/19/22 3:27 AM, Zdenek Dohnal wrote: [Snip] - Till Kamppeter wrote printer applications which covers all printer drivers in Debian distribution - we don't have any additional printer driver package in Fedora, so all our driver packages are covered as well Since there were some questions the last time this came up, see this[0] gnome-control-center upstream discussion for how printer applications may be integrated into the desktop environment printer configuration. - printer applications (the solution for driver-only printers how to work with IPP-only CUPS) are available as SNAPs in Fedora (feel free to try them and leave feedback at the respective OpenPrinting project https://github.com/orgs/OpenPrinting/repositories ), packaging them as RPMs is blocked due dependency on cups-filters 2.0, which is not released yet (though IIRC someone from Fedora community - maybe Brandon Nielsen - has them in copr) That would be me[1], though I haven't been giving them the attention they need lately. [Snip] [0] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1878 [1] - https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: grub2 BIOS booting iso and code
On 4/15/22 5:06 PM, Thomas Schmitt wrote: Hi, Initial test with a CD-R and an HP Compaq 8510w are mixed. It boots to GRUB, but it spins a long time blinking the HDD light displaying nothing but "Welcome to GRUB". It eventually spits out "failure reading sector 0x4f838 from 'hd31'." 'hd31' looks strange for HDD as well as for CD-ROM. Do have that many ? Looked strange to me as well, I don't think I do... Anyway, a reburn fixed it. I can now confirm a CD-R and the aforementioned HP Compaq 8510w boot fine with the test ISO. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: grub2 BIOS booting iso and code
On 4/13/22 6:52 PM, Brian C. Lane wrote: A huge thanks to Thomas Schmitt for posting xorrisofs arguments :) Here is a lorax PR switching to grub2 for BIOS and changing the layout of the iso as described in his post: https://github.com/weldr/lorax/pull/1226 And a Fedora 36 iso: https://bcl.fedorapeople.org/boot-grub2-f36.iso I've tested this with: - qemu bios -cdrom - qemu uefi -cdrom - qemu bios -hda - qemu uefi -hda - USB stick on uefi PC hardware with SB off - USB stick on UEFI PC hardware with SB on - USB stick on Apple hardware UEFI 2010 Macbook Air and 2012 Macbook Pro - Media test works on all of the above I have not tested it on CD or DVD physical media. I have a stack of blank discs but apparently have unplugged all my drives to use their SATA ports for SSDs :) Brian Initial test with a CD-R and an HP Compaq 8510w are mixed. It boots to GRUB, but it spins a long time blinking the HDD light displaying nothing but "Welcome to GRUB". It eventually spits out "failure reading sector 0x4f838 from 'hd31'." and "you need to load the kernel first." before finally presenting me the GRUB menu. Any attempt to launch the installer from the GRUB menu results in the same error messages and return to GRUB menu. The system dual boots Windows 10, if that's meaningful in some way. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possible regression in GNOME in Fedora 36 Branched 20220401.n.0
On 4/3/22 6:45 PM, Ian Laurie wrote: I noticed in VirtualBox with GNOME and 20220401.n.0 that if I resized the VM window when logged into GNOME it slammed me back to the greeter, apparently without killing my login session. I still had a VM from a week ago based on the 1.2 cut, but it was fully updated about a week ago. This VM did not exhibit this issue, but after running latest updates today, it did. I don't know how important VirtualBox is in the grand scheme of things, and don't have an easy way to test this quickly in QEMU/KVM. But if someone else could check this out and can confirm the same, then we need a BZ ticket for it I think. I logged this as a warning for now: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Installation I'm pretty sure I have seen the same in Gnome Boxes, but I haven't had a chance to look into it. It doesn't seem to happen every time. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
On 2/22/22 1:56 PM, Jason L Tibbitts III wrote: Brandon Nielsen writes: I would like to see the forge macros removed from the guidelines if development truly has ceased. I would like to get into them and at least see what needs to change but... the internal implementation is somewhat baroque and my time is severely limited. I think there is good stuff there but I don't know how much work would be required to salvage it. One problem is that at least I thought that significant portions of the Go tooling relied on it, and there's no alternative that has any kind of automation. - J< Looking at this a little more, I'm not really sure we need to be discouraging their use. The code[0] doesn't look that bad to me, and there are only 2 issues open against it. The fact nobody is stepping up to at least comment on the two issues is a bit of a concern. The first one[1] looks really problematic, and I don't see how you can fix it without coordinating with any package using the broken behavior. Hopefully it isn't as bad as it looks? The second one[2] is an RFE, and looks like one I may try to address if nobody gets to it before I have some free time. I do agree with the sentiment elsewhere in this thread that for the majority of cases, it's easy enough to just work with the URLs directly. Maybe the git forge macro documentation moves somewhere else instead? [0] - https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/forge.lua [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2048362 [2] - https://bugzilla.redhat.com/show_bug.cgi?id=2035935 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
On 2/22/22 1:19 AM, Mattia Verga via devel wrote: Il 21/02/22 22:09, Fabio Valentini ha scritto: Hi! I would recommend that you use the standard source handling as documented on the SourceURL page. The forge macros are no longer actively maintained or developed, the last fix / update they received was almost two years ago. The original author is no longer contributing to Fedora, and nobody else seems to understand how the lua scripts behind those macros work. So, shall we remove the reference to %forgemeta macros from the Packaging Guidelines? I'd like to have only one recommended way to make things listed in PG. Having more is confusing for new packagers (and experienced also). The same applies for %autorelease and %autochangelog. Either recommend the use of them or not, instead of saying "pick what you like". It seems to me that these two were adopted in a hurry, but now the development has almost stopped... Mattia I would like to see the forge macros removed from the guidelines if development truly has ceased. I just switched a bunch of stuff I build on copr over, and am now moderately annoyed. Out of date documentation is often worse than no documentation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: CVE-2021-4034: why is pkexec still a thing?
On 1/27/22 10:50 AM, Adam Williamson wrote: On Thu, 2022-01-27 at 08:30 +0100, Milan Crha wrote: On Wed, 2022-01-26 at 15:18 -0800, Adam Williamson wrote: There are still over a dozen packages in the distro that require it: Hi, the gnome-software also calls pkexec is some occasions, once when external appstream data is used (not a thing in Fedora, as far as I know) and when invoking fedora-third-party in some cases. There's no hard require for it in the .spec file. Yeah, I actually started looking last night and found a few other places too :/ gnome-control-center installs a `/usr/libexec/cc-remote- login-helper` which is run by pkexec, for instance. So I guess we're stuck with it :( I have opened an issue upstream[0], as well as prototyped a pkexec free approach[1]. If things go well I can look at gnome-software as well. I really do think splitting out and eventually dropping pkexec is a worthwhile goal. Feedback welcome! [0] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1604 [1] - https://gitlab.gnome.org/nielsenb-jf/gnome-control-center/-/tree/41.2-no_cc-remote-login-helper ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On 1/26/22 3:25 AM, Roberto Sassu via devel wrote: [Snip] - web servers or other kind of servers where you, as client, would like the guarantee that your data is processed only if the software running in the server is not compromised For what it's worth, I, and several people I work with, have been hoping for something to enable this kind of functionality for quite some time now. Hope to see more about it soon! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
On 12/17/21 11:22 AM, Sandro Mani wrote: On 17.12.21 16:55, Sandro Mani wrote: On 17.12.21 16:13, Michael J Gruber wrote: On 12/15/21 4:11 AM, Michael J Gruber wrote: Sorry to pile on but I somehow lost the original e-mail. "/usr/share/tessconfigs" seems to be missing so output to PDF or txt fails with "read_params_file: Can't open txt" or "read_params_file: Can't open pdf". Standard out works. Issue is similar to one mentioned upstream[0]. [0] - https://github.com/tesseract-ocr/tesseract/issues/3411 How exactly do you reproduce this problem? mupdf (mutool) works with the tesseract5 build (tested on F35, though), as does PyMuPDF. It's reproducible via command line, say tesseract out image.tif PDF The CMake build scripts are pretty broken, they omit installing lots of stuff. I've reverted to autotools, but unfortunately there is some brokenness with ARM NEON detection which I'm trying to fix up Should be good now Sandro Works great, thank you so much! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
On 12/15/21 4:11 AM, Michael J Gruber wrote: Are you planning to bring these to F35, as well? Tesseract-5.0.0 appears to be mostly a bugfix release along with some other improvements, so I dunno (and haven't tested so far - the heads up was a few hours before the push). Sorry to pile on but I somehow lost the original e-mail. "/usr/share/tessconfigs" seems to be missing so output to PDF or txt fails with "read_params_file: Can't open txt" or "read_params_file: Can't open pdf". Standard out works. Issue is similar to one mentioned upstream[0]. [0] - https://github.com/tesseract-ocr/tesseract/issues/3411 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
On 11/29/21 1:33 PM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Users_are_admins_by_default_in_Anaconda = Users are administrators by default in the installer GUI = == Summary == The Anaconda installer GUI will have the administrative rights checkbox on the User screen ticked by default. == Owner == * Name: [[User:Vladimirslavik| Vladimir Slavik]] * Email: vsla...@redhat.com == Detailed Description == Currently, the Anaconda installer GUI presents an unticked checkbox "Make this user administrator" on the user setup screen by default. This means users have to discover the control, understand its meaning, and consciously decide to change the value from the default one. [Snip] I find this wording confusing, and I've been using Linux for at least 15 years now. I think if we're making changes to reduce user confusion we may want to change the wording as well? Perhaps a better wording would be "Grant user administrator privileges (allow sudo)"? Something to make it clear the resulting user isn't root, but can act as root. I had always assumed the "Make this user administrator" checkbox meant the created user would effectively _be_ root, just with a different username. After playing with yesterday's KDE rawhide compose, I boldly decided to check the box. Apparently what it really means is the created user is a member of the wheel group and can use sudo. This also appears to disable the root user spoke in Anaconda. The resulting install fixes one of my biggest gripes with the KDE spin. So I say the checking it by default part of the change proposal is great! Why was I not checking this all along? As mentioned in the change proposal this basically matches what happens with the user gnome-initial-setup creates so it's a consistency win as well. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
On 11/29/21 1:33 PM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Users_are_admins_by_default_in_Anaconda = Users are administrators by default in the installer GUI = == Summary == The Anaconda installer GUI will have the administrative rights checkbox on the User screen ticked by default. == Owner == * Name: [[User:Vladimirslavik| Vladimir Slavik]] * Email: vsla...@redhat.com == Detailed Description == Currently, the Anaconda installer GUI presents an unticked checkbox "Make this user administrator" on the user setup screen by default. This means users have to discover the control, understand its meaning, and consciously decide to change the value from the default one. However, computer usage by individuals is heavily skewed towards single user machines where the (sole) user has administrative powers over the machine by invoking `sudo`. This has been always reflected by the design of the screen, which allows only a single user to be created. The GNOME first time setup also creates a single user - and makes them an administrator without asking. The proposed change merely changes the default GUI state to be in line with this expectation. Further, this change of defaults complements the default for root account. The redesign of root setup screen in Fedora 35 makes it clear that root should be left locked. This change makes it clear that the user should be the administrator. Together, these defaults will let the user satisfy all user account options by filling in nothing more than the user name and the password (twice to confirm). [Snip] == How To Test == Start Anaconda installer for the Server variant, open the user setup screen, "Make this user administrator" is checked = pass. Should be variant / spin / hardware agnostic, with the caveat that the presence of user screen is configurable, so in many cases the screen is not reachable. Kickstart installs are not affected. [Snip] "Detailed Description" section mentions GNOME, "How To Test" describes the server variant. Which specific variants does this all apply to? If I recall correctly, the KDE spin already differs from Workstation in this regard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Should fedora workstation incude cups by default
It has been included as far as I remember (just go to localhost:631 to check). It is still included in F35. As far as I know there are no plans to remove it for F36, so it still exists in Rawhide. On 10/25/21 2:52 AM, Felipe Borges wrote: On Fri, Oct 22, 2021 at 1:42 AM Reon Beon via devel wrote: I don't know if it did by default on rawhide (gnome). As far as I remember. Why would we want that? Was there a previous discussion on the $SUBJECT that I might not be aware of? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Linux Plumbers Conference - Open Printing Micro Conference
On 9/23/21 9:01 PM, Brandon Nielsen wrote: [Snip] For anyone looking to play with these right now without a snap, I've started a copr[0]. I don't have the systemd service working yet, but you can start the printer app server manually. It gives you a good feel for where the project is going. [0] - https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/ I have the services working as well now for people looking to experiment with installing a printer system wide. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Linux Plumbers Conference - Open Printing Micro Conference
On 9/25/21 8:55 PM, Solomon Peachy wrote: On Thu, Sep 23, 2021 at 09:01:07PM -0500, Brandon Nielsen wrote: For anyone looking to play with these right now without a snap, I've started a copr[0]. I don't have the systemd service working yet, but you can start the printer app server manually. Can you round out the set with the hplip and gutenprint applications too? https://github.com/OpenPrinting/hplip-printer-app/ https://github.com/OpenPrinting/gutenprint-printer-app/ The latter in particular is of considerable interest to me, and I'd prefer to not have to deal with the snap ecosystem. - Solomon Done. Earlier caveat still applies, I don't have the service working correctly. You can start the server manually. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Linux Plumbers Conference - Open Printing Micro Conference
On 9/22/21 12:54 AM, Zdenek Dohnal wrote: On 9/21/21 1:21 PM, Neal Gompa wrote: On Tue, Sep 21, 2021 at 5:36 AM Zdenek Dohnal wrote: - several other printer applications was implemented by Till Kamppeter[1][2][3][4] - Till makes it available as Snaps, I'm planning to package it into Fedora as rpm first, then later as a flatpacks How would these even work as Flatpaks? They are not graphical applications or even console applications. These are helper services for CUPS. I wouldn't expect those to work in Flatpak at all. (here I'm starting to talk based on talks I've seen and how I've understood them - I still haven't had time to deeply test them by myself, I've only tried briefly lprint last year...) Actually they are console applications - you can start them by CLI as an user or make them start on startup by its service unit. Once you configure your device at http://localhost:8000 (web ui for the printer application), your device will become available via mDNS and you can print without any other configuration (if your mDNS support in Fedora works). Or if you don't trust your local network, you can install the queue with uri - |ipp://localhost:8000/ipp/print/| Ad printer apps being in flatpack - as you can see in the github issue[1], ps-printer-application and hplip-printer-application are available in SNAP repositories (CUPS has its SNAP as well in SNAP store). IIUC flatpack is based on the similar technology as snap, so my thoughts were the flatpack version is also possible. [1] https://github.com/OpenPrinting/ps-printer-app/issues/9 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure For anyone looking to play with these right now without a snap, I've started a copr[0]. I don't have the systemd service working yet, but you can start the printer app server manually. It gives you a good feel for where the project is going. [0] - https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PWG virtual meetup 2021
On 5/7/21 12:01 AM, Zdenek Dohnal wrote: On 5/6/21 9:36 PM, Brandon Nielsen wrote: Would you want to see that ported to a "How to debug printing problems" Quick Doc[0]? Probably under "Usage and customisation"? I could take a crack at a draft. [0] - https://docs.fedoraproject.org/en-US/quick-docs/ Hi Brandon! Thank you for looking into it! IMO it would be nice to have a separate category (for Printing and then a separate for Scanning) like kernel, databases or virtualization have - it would be lost in 'Usage and customisation' group. It is because the wiki page doesn't cover only 'How to debug printing problems', but it covers more terminology, tricks, known issues, user stories and (finally) how to debug and file the report - so it would be nice to have subcategory for all of those. And IMHO Fedora Linux's user base is mostly on desktop, it makes sense to me to have printing and scanning on the main page. If it is possible and you agree too, please let me know once you have a time to create a draft :) Again, thank you very much! Zdenek I started on this last night and based on the sheer quantity of documentation I agree 100%. It should probably be it's own "Printing and scanning" category or categories. I'm converting it as a bunch of "partials" so it can be reorganized easily. You can see the start of my work in pagure[0], I tried to add you as a collaborator to the branch, let me know if I did it wrong. I still need to clean up a lot of the formatting and intra-document links as well as split it out into the categories mentioned above. But all of the text should be there. I also pinged the docs group to see if they have any suggestions[1]. [0] - https://pagure.io/fork/nielsenb/fedora-docs/quick-docs/tree/printing-debug [1] - https://lists.fedoraproject.org/archives/list/d...@lists.fedoraproject.org/thread/K7VSSF3Q26CINGMU5PECARZJ7N7XQSEQ/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PWG virtual meetup 2021
On 5/6/21 12:18 AM, Zdenek Dohnal wrote: [Snip] More terminology and tricks here [1] and here [2]. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Terminology_for_printing_and_scanning [2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Useful_tricks P.S. I know the page should be rewritten into docs.fedoraproject (I and Matt even talked together about it once), I have never got a time to do that. So if someone is willing to rewrite it in docs.fedoraproject, give me access to edit it and merge the changes, that person is very welcomed :) Would you want to see that ported to a "How to debug printing problems" Quick Doc[0]? Probably under "Usage and customisation"? I could take a crack at a draft. [0] - https://docs.fedoraproject.org/en-US/quick-docs/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
On 3/29/21 6:02 PM, Kevin Fenzi wrote: On Sat, Mar 27, 2021 at 11:02:58PM +0100, Björn Persson wrote: Kevin Fenzi wrote: I'd like us to add security query/respond pairs. Those can very easily weaken security, as the answers are often public and easy for an attacker to look up, especially when there are only a few predefined questions to choose from. I was not advocating predefined questions. :) If I can enter my own question, then I can come up with some things that only I and my family know. That requires careful and security- conscious consideration. Many people would come up with insecure questions. Well, I always use randomly generated words for mine. But I agree, some people would make poor choices there. There's a limited supply of such personal secrets that I can be sure I'll remember, so I can't do that for too many sites. It also requires a not too public life. People who publish their entire lives on Facebook will have trouble coming up with a question that an attacker can't find the answer to. Another reason to randomly generate. [Snip] But if randomly generating is best practice, why not automate it for the user in the form of recovery codes? Take away the temptation to do something insecure. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
On 3/26/21 3:36 PM, Matthew Miller wrote: On Fri, Mar 26, 2021 at 03:26:53PM -0500, Brandon Nielsen wrote: This is pretty common in my experience; it seems like password managers should support this pattern. I can't say I have ever appended an OTP to a regular password, and I use 2FA everywhere I can. Maybe more so on the enterprise-login side than on websites which have added it as a feature? I guess by "pretty common" I mean: both RH's single-sign-on and the one for my previous university job worked this way. So, for my sample size of two, it's very common. :) Additionally, combining a password manager managed password with an OTP has always felt a little bit like working across purposes to me, essentially combining both factors behind a single primary password. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
On 3/26/21 3:24 PM, Matthew Miller wrote: On Fri, Mar 26, 2021 at 02:48:39PM -0400, Christopher wrote: [Snip] * In many places, including accounts.fedoraproject.org, in order to log in, you have to append the OTP to your password, so it doesn't really play nice with password managers. This is pretty common in my experience; it seems like password managers should support this pattern. I can't say I have ever appended an OTP to a regular password, and I use 2FA everywhere I can. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Building custom kernels
On 2/28/21 12:00 PM, Julian Sikorski wrote: W dniu 27.02.2021 o 20:59, Julian Sikorski pisze: Hi, I am trying to test some Renoir s2idle patches [1]. It appears that Fedora kernel source is now maintained on gitlab as kernel-ark [2]. What I tried is adding the patches to the fedora-5.11 branch and running make dist-srpm, but it failed due to config mismatch on CONFIG_INIT_STACK_NONE: Processing /home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config ... Error: Mismatches found in configuration files Found CONFIG_INIT_STACK_NONE=y after generation, had CONFIG_INIT_STACK_NONE=is not set in Source tree make[1]: *** [Makefile:145: dist-configs-check] Błąd 1 Is this expected? Is there a better way of testing patches on Fedora kernels? Thanks for the help in advance. Best regards, Julian [1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230 [2] https://gitlab.com/cki-project/kernel-ark Hi, the same keeps happening if I try to merge os-build into agdf5 tree or even if I try to make srpm in the ark-latest branch. Is this normal? Best regards, Julian I found the same last week and the documentation[0] feels really unloved. I eventually resorted to rebuilding from the SRPM and apply patches there. [0] - https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 2/19/21 3:47 PM, Tom Seewald wrote: Well, the idea would be for us to put it into Rawhide and do a series of test days/weeks to get feedback and close any remaining gaps. If it doesn't manage to pull through by beta freeze, then we would revert and push it back to Fedora 35. Did these test days/weeks ever happen? I don't recall seeing an announcement or any talk about their results. Final preparations are happening now: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/OZ62EIL7ZAS5HL6ZW7DE6TFE6EW7A2IA/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On 2/8/21 2:44 PM, Chris Murphy wrote: On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote: Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. You mean get rid of it (from media and installations)? Because we install it unconditionally already, even though it's a BIOS only utility and there isn't a boot entry for it in the bootloader. It's a bit obscure how to use it, given there's no menu entry for it. There's also the fact it doesn't seem to work real well with modern hardware[0][1]. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1815742 [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869211 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 11/25/20 8:18 AM, Wim Taymans wrote: So, the current sentiment is: * provide an easy way to test in f33, either copr or with regular packages. - rawhide is a not a good place to get good testing anyway * encourage people to test. Provide instructions on how to do this and how to leave feedback. * Carry this over to f34, probably with just the packages/easier switch. * propose permanent switch for f35 - it gets at least full cycle of testing (f34 + part of f33) * re-evaluate situation for f35 beta freeze to make a default switch. Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch? Wim My intention in stating my wishes this could be tested more widely was not to discourage this as a change for F34. I just hoped that since the change request states PipeWire is intended to work as a drop-in replacement for PulseAudio, that we could find a way to drop it in for at least Fedora 33 (copr, whatever), and hopefully maximize the test coverage. I figured more, easier, testing would make everybody more comfortable with inclusion in F34. Even if it can't be an easy drop-in, I would at least like to see the documentation updated for how to hack it in, since apparently the symlink method is no longer the intended method. No matter what, thank you so much for working so hard to improve the state of A/V in Linux! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 11/23/20 11:48 AM, Adam Williamson wrote: On Mon, 2020-11-23 at 18:20 +0100, Tomasz Torcz wrote: On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote: On 11/20/20 5:26 PM, Ben Cotton wrote: The pulseaudio package will be uninstalled and pipewire-pulse will be installed. pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34 IMO, this alone disqualifies this plan. Fedora should be a stable end-user distro and not a testing site for eager devs to test their immature and incomplete works. I think Fedora should establish strong "no regressions" rule when replacing system software like this. PulseAudio has had 15 years of development, features and fixes. It is hard to believe pipewire is as capable as a replacement now. I disagree. This would be incompatible with the "First" foundation. If we'd had a "no regressions" rule for pre-PA audio, we'd probably never have landed PA, or not for years. Are things on the whole better since we did? I'd say yes. Will our first release with pipewire probably have some bugs that constitute regressions from the previous audio setup? Almost certainly. Especially given the sheer amounts of stuff people do - see your config below - I think we'd find it difficult to have a "no regressions" rule and still be Fedora. Part of Fedora's job is to adopt new things and shake some of the initial bugs out of them. Of course we would need to start with collecting the use cases, and this will be different for every user. For example, I frequently use my laptop with 3 sound devices present: built-in speakers, speakers connected to USB-C dock and bluetooth headphones*. I use pavucontrol to route applications to proper output/input and I expect this to work the same with PW. This is important to me. Did that all work with the first Fedora with PA in it? I bet not. Would we have as capable a PA today if Fedora hadn't taken the leap to include PA? Probably not. > [Snip] PulseAudio wasn't necessarily purporting to be a drop-in replacement for Alsa. It seems like if PipeWire really is going to be swappable like the change text notes[0], we should be looking at this as a rare opportunity to get really widespread testing with a potentially majorly breaking change by offering the ability to easily swap it in and test in already released versions. That way we could be "first" and "battle hardened" at the same time. Unfortunately, as noted elsewhere in this thread, there really isn't a way to test outside of Rawhide currently[1][2][3]. It seems like the packages are there and should work, but might not[4]? As I've mentioned elsewhere, I'm not saying handling changes like this should be mandated[5], or even required in this specific case, or elsewhere. But I think there would be less pushback to the change if this was the course of action. [0] - "This proposal is to replace the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak." [1] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KNQXW2XNVS4KVGHBONNWIUWXBSCRBGRV/ [2] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LITC357UASWMUBFCVDHOPOG2B4W3VMI6/ [3] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RLCQAMCUASZ764LQ2YQ7PXYKNZVVKJX7/ [4] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4OZXC2FSFPOZ5EJS4M5YNCEADIAHOGNF/ [5] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E262AGSRXKUZ5SYR6IP3TQ4JJMBDWKGS/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 11/23/20 10:30 AM, Andreas Tunek wrote:
Den lör 21 nov. 2020 kl 15:31 skrev James Szinger <mailto:jszin...@gmail.com>>:
On Fri, 20 Nov 2020 18:35:19 -0600
Brandon Nielsen mailto:niels...@jetfuse.net>>
wrote:
> If it has changed, it would be really great if pipewire-pulse could
> make it into the F33 repos so it could be easily tested.
I agree. I think new software should be available and testable on a
stable Fedora release before it becomes default. I’m not ready to
have a rawhide install on real hardware to test something that’s not
ready yet. I am especially wary of a change that requires new
software to be written between now and beta.
I think this is a way too high burden on new features. Testing in
rawhide should be enough. Something like pipewire is also pretty easy to
test in a Live system.
[Snip]
Easy to test basic things like sound works, headphones work, output
device changing works. Much more difficult to test every audio use-case
I use in a given day, week, month, because needs and uses change so
much. Am I using my Bluetooth headphones today? A USB audio interface?
Webcam? HDMI? Plus I work across different systems with almost entirely
different hardware. I may be willing to run Rawhide on some of these
systems, but most people probably won't.
I'm not saying this should necessarily be a mandate. But for something
completely fundamental to how a lot of people use their systems,
especially now, with such a wide array of hardware and uses, we should
absolutely be pursuing the widest possible test coverage. And right now,
the only answers are "it works in rawhide" and "it will be feature
complete later".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 11/21/20 6:00 PM, Brandon Nielsen wrote: [Snip] I feel like for something as fundamental to the desktop experience as audio a few test days would really expose all of the pain points. At least personally my uses of audio vary quite a bit day to day and week to week, especially in the current environment. _Wouldn't_ really expose all the pain points. I would be a lot happier if there was a documented way to enable this for F32 / F33 so the brave could try living with it for a prolonged period of time. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 11/21/20 4:05 PM, Neal Gompa wrote: On Sat, Nov 21, 2020 at 4:57 PM Tom Seewald wrote: So has this essentially been decided on by the working group? If not, what concerns would be listened to? Well, the idea would be for us to put it into Rawhide and do a series of test days/weeks to get feedback and close any remaining gaps. If it doesn't manage to pull through by beta freeze, then we would revert and push it back to Fedora 35. I feel like for something as fundamental to the desktop experience as audio a few test days would really expose all of the pain points. At least personally my uses of audio vary quite a bit day to day and week to week, especially in the current environment. I would be a lot happier if there was a documented way to enable this for F32 / F33 so the brave could try living with it for a prolonged period of time. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 11/20/20 4:31 PM, Naheem Zaffar wrote: On Fri, 20 Nov 2020 at 19:47, Brandon Nielsen <mailto:niels...@jetfuse.net>> wrote: On 11/20/20 1:28 PM, Dominique Martinet wrote: > Ben Cotton wrote on Fri, Nov 20, 2020: l the pipewire-pulse library (which >> removes the pulseaudio package). > > Took me some time to figure out how to test: [Snip] Me too. I think for current F33 / Rawhide you're expected to create some symlinks manually: https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165 <https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165> I don't think this is the the correct way any longer. Lib-Pulse was AFAIK the initially planned drop-in replacement for pulseaudio. This has since been deprecated. Pipewire-Pulse AFAIK provides a separate pulseaudio server. I dont think it needs any linking, other than software activation. It would be great however if the change request clarified what needs to be done - especially taking into account that very recent online instructions now may be wrong. If it has changed, it would be really great if pipewire-pulse could make it into the F33 repos so it could be easily tested. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 11/20/20 1:28 PM, Dominique Martinet wrote: Ben Cotton wrote on Fri, Nov 20, 2020: == How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio. To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package). Took me some time to figure out how to test: [Snip] Me too. I think for current F33 / Rawhide you're expected to create some symlinks manually: https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165 ___ 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: Mock needs more space
On 11/20/20 2:03 AM, Pavel Raiskup wrote: On Friday, November 20, 2020 2:42:08 AM CET Brandon Nielsen wrote: I'm attempting an armhfp build with mock and it insists it needs "At least 243MB more space needed on the / filesystem." This seems to be a bug in RPM: https://bugzilla.redhat.com/show_bug.cgi?id=1895363 Work-around is to disable bootstrap in that particular chroot. Pavel I have 1.1 TB free on /, so I'm assuming there's some kind of limit set somehow, but I can't figure out how to adjust it. I don't see anything that looks promising in the config files, or the manpage. Anybody have a clue for me? I can confirm, passing '--no-bootstrap-chroot' works around the issue. Thank you so much! ___ 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
Mock needs more space
I'm attempting an armhfp build with mock and it insists it needs "At least 243MB more space needed on the / filesystem." I have 1.1 TB free on /, so I'm assuming there's some kind of limit set somehow, but I can't figure out how to adjust it. I don't see anything that looks promising in the config files, or the manpage. Anybody have a clue for me? ___ 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: GVim issues
I have been using it pretty much daily and haven't had any issues. Is this only with F33? I have only just updated my "work" machines. Possibly a misbehaving plugin? On 10/29/20 11:29 AM, Vít Ondruch wrote: Does anybody experience issues with GVim? It happens quite often, that it stops updating the UI. It seems it does something in background (e.g. the mouse cursor is changing and window title updating), but the UI is completely stuck. I am not really sure how to analyze this issue and where to report it. Is it GVim issue? Or (X)Wayland issue? Clutter? GTK? Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages (including pdc-client) looking for new maintainers
On 10/20/20 2:14 PM, Neal Gompa wrote: On Tue, Oct 20, 2020 at 3:11 PM Miro Hrončok wrote: On 10/20/20 9:08 PM, Brandon Nielsen wrote: I would be interested in taking celt071 if nobody else wants it. I use Mumble regularly. See also https://pagure.io/fesco/issue/2478#comment-695972 I adopted it before seeing this comment, and then orphaned it again afterward. Whoops! Fair enough, I retract my interest! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages (including pdc-client) looking for new maintainers
On 10/19/20 4:55 AM, Miro Hrončok wrote: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life [Snip] I would be interested in taking celt071 if nobody else wants it. I use Mumble regularly. The only wrinkle is I'm not currently a packager, though I do have a package in review[0] that I grossly underestimated the complexity of. I was hoping to get rnnoise[1] included in Fedora and enabled in Mumble. I already have it packaged[2] and was hoping to submit it after the hundred years war with my first package reached its conclusion, but perhaps I should submit it for review now in the hopes of being able to adopt celt071? [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1350884 [1] - https://github.com/xiph/rnnoise [2] - https://copr.fedorainfracloud.org/coprs/nielsenb/mumble/package/rnnoise/ ___ 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: F33 Workstation/btrfs: Can't reinstall while preserving /home
On 10/9/20 12:02 PM, Christopher Engelhard wrote: Hi, I just tried to reinstall a Fedora 33 Workstation system that uses the F33 default btrfs partitioning (i.e. subvolumes for / and /home). I can't seem to find an option to install to / while preserving the /home subvolume, Anaconda insists on a reformatted partition for root - which would of course wipe /home as well. Am I missing something? Christopher It's certainly a little different. See if an answer in this thread works for you: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/VZFJ2MWPJLSP3RFCWN4H7MWDXXWEXLNL/ ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 3:14 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 22:11, Brandon Nielsen wrote: That link shows security fixes for 68.x from only a week ago. August 25, 2020 (68.12) vs. September 22, 2020 (78.3). But still, the last 68. release was 5 days ago[0], hardly seems unsupported. Sorry for all the spam. [0] - https://www.thunderbird.net/en-US/thunderbird/68.12.1/releasenotes/ ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 3:11 PM, Brandon Nielsen wrote: On 10/6/20 3:03 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:48, Brandon Nielsen wrote: Yes, but they clearly don't expect updates to work given the changes mentioned later in this thread and the release notes, and Fedora has users that will be updating that need to be considered. 78.3.1 includes security fixes[1]. 68.x has reached its EOL and will no longer receive updates and fixes. [1]: https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/ That link shows security fixes for 68.x from only a week ago. I lied, no it doesn't. Their advisory numbers don't work how I thought. So really, this is a no win no matter what the ultimate decision is. ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 3:03 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:48, Brandon Nielsen wrote: Yes, but they clearly don't expect updates to work given the changes mentioned later in this thread and the release notes, and Fedora has users that will be updating that need to be considered. 78.3.1 includes security fixes[1]. 68.x has reached its EOL and will no longer receive updates and fixes. [1]: https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/ That link shows security fixes for 68.x from only a week ago. ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 2:45 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:24, Brandon Nielsen wrote: Sounds to me they don't expect 78.2.1 to be entirely compatible with profiles from the previous version. $ rpm -qa thunderbird thunderbird-78.3.1-1.fc32.x86_64 Version 78.3.1 is production ready. Mozilla has made it available to all Thunderbird users on all supported platforms. $ rpm -qa thunderbird thunderbird-68.11.0-1.fc32.x86_64 Yes, but they clearly don't expect updates to work given the changes mentioned later in this thread and the release notes, and Fedora has users that will be updating that need to be considered. ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 2:22 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:08, Gordon Messmer wrote: I definitely think this should be rolled back. We're past the beta freeze, and IMO, this violates the updates policy which states "Package maintainers MUST: Avoid Major version updates, ABI breakage, or API changes if at all possible." Thunderbird's update is not broken, it has no API/ABI breakages. Everything works just fine. Personally, I think this change warrants its own self-contained change proposal in the next release of Fedora, even though Thunderbird 68 will not receive updates after Sep 2020 OpenPGP is now build-in into Thunderbird core. No third party addons required. One way or another, I need to roll back until SOGo has time to finish porting their extension to the new API. After rolled back, the Lightning extension isn't enabled or even visible in Add-ons, so I have to figure out how to fix that. Fedora is a bleeding edge distribution. If you need a legacy version of any package, you can always build it in COPR. I want to use the most recent version. While I agree with wanting the latest version, and it doesn't break anything I use, from the release notes linked above: "Thunderbird version 78.2.1 is only offered as direct download from thunderbird.net and not as an upgrade from Thunderbird version 68 or earlier. A future release will provide updates from earlier versions. Automatic updates are available for users already running version 78.0 or higher." Sounds to me they don't expect 78.2.1 to be entirely compatible with profiles from the previous version. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 blocker status , with CALL FOR TESTING on abrt/libreport
On 9/12/20 5:10 PM, Chris Murphy wrote: This is pending for 3 days, so --advisory doesn't work since it's still not in u-t. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fd3d0e6879 Instead I did bodi updates download --updateid=FEDORA-2020-fd3d0e6879 dnf update *rpm And it skips a bunch of rpms that get downloaded as part of that update, but aren't already installed. Here's what I discovered following that: https://bugzilla.redhat.com/show_bug.cgi?id=1878317 Thanks for that! I get bug 1873029[0]. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1873029#c16 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 blocker status , with CALL FOR TESTING on abrt/libreport
On 9/11/20 3:44 PM, Adam Williamson wrote: On Fri, 2020-09-11 at 15:50 -0400, Ben Cotton wrote: Accepted blockers - 1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — ON_QA abrt-server errors when processing zstd compressed core dumps produced by systemd-246~rc1-1.fc33 FEDORA-2020-59e144acee contains a potential fix, but appears to introduce a new blocker (BZ 1873029). It may be moot until the retrace server is brought back online. The infra team has provisioned a basic instance, which msuchy is working to get ready for use. So yeah: it would really help if other folks could try installing the update and see if they are able to successfully file a crash bug or not. Please report your findings to the bug report(s). Is there an easy way to install the update? It's been "unpushed", so the command to install (`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-59e144acee`) it doesn't seem to work. ___ 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 by default status updates, 2020-08-23
On 8/24/20 1:29 PM, Brandon Nielsen wrote: On 8/23/20 10:24 PM, Chris Murphy wrote: [Snip] - Communication: + Fedora Magazine article "Btrfs Coming to Fedora 33" will be published Monday, 24 August. - Documentation: + A partial list of docs needing updates https://pagure.io/fedora-workstation/issue/158#comment-672898 https://lists.fedoraproject.org/archives/list/d...@lists.fedoraproject.org/message/R5LKDK42VAIVSKC4NCLIMJCUKJRFGAO5/ Assistance in updating is appreciated, but in particular it'd be most helpful to find additional weak spots that have not yet been identified. Will either of the above cover preserving home directories between installs[0]? [0] - https://lists.fedoraproject.org/archives/list/d...@lists.fedoraproject.org/message/R5LKDK42VAIVSKC4NCLIMJCUKJRFGAO5/ Sorry, wrong link, I meant this: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/VZFJ2MWPJLSP3RFCWN4H7MWDXXWEXLNL/ ___ 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 by default status updates, 2020-08-23
On 8/23/20 10:24 PM, Chris Murphy wrote: [Snip] - Communication: + Fedora Magazine article "Btrfs Coming to Fedora 33" will be published Monday, 24 August. - Documentation: + A partial list of docs needing updates https://pagure.io/fedora-workstation/issue/158#comment-672898 https://lists.fedoraproject.org/archives/list/d...@lists.fedoraproject.org/message/R5LKDK42VAIVSKC4NCLIMJCUKJRFGAO5/ Assistance in updating is appreciated, but in particular it'd be most helpful to find additional weak spots that have not yet been identified. Will either of the above cover preserving home directories between installs[0]? [0] - https://lists.fedoraproject.org/archives/list/d...@lists.fedoraproject.org/message/R5LKDK42VAIVSKC4NCLIMJCUKJRFGAO5/ ___ 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
Advice for packaging a TI msp430 cross compiler
I have been working toward getting a "modern" cross compiling toolchain included in Fedora[0] ever since mspgcc stopped working[1] 4 years ago. Up until recently, my efforts have been almost entirely centered around packaging TI / Mitto Systems' somewhat bespoke branch of GCC[2]. It has been suggested[3] that my efforts may be better focused on having msp430-none-elf (and possibly msp430-none-elf-bare) added as an arch to the cross-gcc / cross-binutils packages. This would require building a msp430-none-elf-newlib package as well. I have managed to build modified cross-gcc and cross-binutils packages with a matching newlib package. Code compiles and links, but the resulting binary does not actually work on the micro. I suspect the correct linker script is not being used, but I have not had time to investigate further and am somewhat over my head in building and troubleshooting cross compilers. Which path forward is recommended? Option one, the bespoke branch, already produces a working toolchain[4]. Option two, modified cross-gcc / cross-binutils has a lot more appeal being 'vanilla' upstream, and adds the possibility of supporting the 'bare' msp430 target, but I'm a bit lost in how to get the parts to produce a functional binary. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1350884 [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1175942 [2] - https://www.ti.com/tool/MSP430-GCC-OPENSOURCE [3] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KAYAKXOY7ZPQEENB6PUM2EEUN53X2HQQ/ [4] - https://copr.fedorainfracloud.org/coprs/nielsenb/msp430-development-tools/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 aarch64 build failures on copr
On 7/29/20 6:09 PM, Jeff Law wrote:
On Wed, 2020-07-29 at 17:14 -0500, Brandon Nielsen wrote:
On 7/29/20 4:40 PM, Jeff Law wrote:
ACK. I don't see msp430-development-tools in the standard fedora repos. So
I'll
leave it to you to fix the package in whatever repo it lives in.
Also note, you may ultimately be better off getting msp430 added to the cross-
{binutils,gcc} packages rather than creating a new package.
Jeff
It's a work in progress[0].
As for cross-gcc and friends, the description notes those are for
building kernels only, is that not the case?
It shouldn't matter for cross-binutils and cross-gcc.
There's also some vanilla upstream / TI upstream compatibility weirdness
to consider...
That issue should be resolved by getting those patches upstreamed to the GCC
project. Your best contact point for that would be Jozef Lawrynowicz <
joze...@mittosystems.com>
Jeff
Great! I'll look into it, 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
Re: Fedora 32 aarch64 build failures on copr
On 7/29/20 4:40 PM, Jeff Law wrote:
ACK. I don't see msp430-development-tools in the standard fedora repos. So
I'll
leave it to you to fix the package in whatever repo it lives in.
Also note, you may ultimately be better off getting msp430 added to the cross-
{binutils,gcc} packages rather than creating a new package.
Jeff
It's a work in progress[0].
As for cross-gcc and friends, the description notes those are for
building kernels only, is that not the case?
There's also some vanilla upstream / TI upstream compatibility weirdness
to consider...
[0] - https://bugzilla.redhat.com/show_bug.cgi?id=1350884
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 aarch64 build failures on copr
On 7/28/20 4:39 PM, Jeff Law wrote:
On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
If this is a new failure (say in the last week), it could be an out
of memory
scenario. Try disabling LTO. The standard way to do that is
%define _lto_cflags %{nil}
In your %build stanza in the spec file.
Heff
I agree, it's almost certainly OOM because it says "fatal error:
Killed." I've never seen that happen for any reason other than OOM.
I've seen it happen for a variety of reasons. Please test with LTO disabled and
let me know if that helps.
jeff
Disabling LTO with '%define _lto_cflags %{nil}' fixed it.
___
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: Help with reviewing a compiler toolchain
On 7/28/20 3:46 PM, Andy Mender wrote: Dear Fedorians, I really need some help with a review of a GCC toolchain variant I've started recently: https://bugzilla.redhat.com/show_bug.cgi?id=1350884 A Koji build of the most recent SRPM: https://koji.fedoraproject.org/koji/taskinfo?taskID=48035045 Some minor issues have been fixed already, but the toolchain seems quite complicated and frankly it went over my head :(. I'd be more than happy to review someone else's package(s) in exchange. Cheers, Andy Oh hey, it's my review request. Sorry I'm so clueless. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 aarch64 build failures on copr
I've been seeing build failures for Fedora 32[0][1][2], always the same failure: "xgcc: fatal error: Killed signal terminated program cc1plus" I can't find any more detail than that. These builds succeed locally with mock. The copr failures are reproducible so I'm sure I'm doing something wrong, but I can't figure out what. Any ideas? [0] - https://copr.fedorainfracloud.org/coprs/nielsenb/msp430-development-tools/build/1577708/ [1] - https://copr.fedorainfracloud.org/coprs/nielsenb/msp430-development-tools/build/1565812/ [2] - https://copr.fedorainfracloud.org/coprs/nielsenb/msp430-development-tools/build/1565363/ ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On 7/18/20 5:09 PM, John M. Harris Jr wrote: On Saturday, July 18, 2020 3:25:35 AM MST Benjamin Berg wrote: But thrashing scenarios are exactly that, *technically* running but *practically* dead. Thrashing doesn't mean the system is unusable, or anything of the sort. It's only an issue if you're thrashing for too long. I think it only makes sense to continue a discussion if you acknowledge the existence and really understand the scenario described here: https://lkml.org/lkml/2019/8/4/15 I've linked to that very thread several times in this thread. The bug here is in the web browsers that cause that behavior. The solution is to either fix the web browsers or limit the amount of memory they can run away with. What about the case of the developer whose code accidentally does something that blows through all available memory, leading to swap thrashing. I've been there. The system is very much unusable, to the point where a user without the knowledge of the magic sysrq key will almost certainly be reaching for the power button. Or when a compile takes more memory than you expect, leading to the same? Again, I've been there. The system is absolutely unusable for any regular user use-case I can think of. Decompression "bomb" (malicious or otherwise) on a memory taxed system? Again, definitely unusable. Web browsers are definitely not the only way thrashing can be encountered. While I agree resource limits via cgroups or other method are needed, an EarlyOOM emergency brake is definitely welcome as well. The kernel OOM killer is certainly not adequate for an interactive user session in my experience. ___ 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: memory testing
On 7/15/20 12:11 PM, Chris Murphy wrote: Hi, While bad RAM is uncommon, it comes up with some regularity to cause folks a lot of grief. I'm wondering if there's a way to make it easier to get bad news :-\ In particular there are cases where RAM defects just don't show up with a few hours of memtest86+, it can take days of contiguous testing, which is so inconvenient the test itself seems worse. Here's what I've got so far: 1. Fedora includes /boot/memtest86+-5.01 on every installation. But this is a legacy/BIOS program. The idea of recommending folks enable CSM/legacy BIOS just to test their RAM is questionable because it means disabling UEFI Secure Boot to do it. Lie in wait malware is perhaps rare but plausible. UEFI native memtest86+ is not free so it can't be included. I kinda wonder if including this should be deprecated? While I consider the effort to keep Memtest86+ working in Fedora pretty heroic, and I've never had it fail to detect bad memory for me, I feel like shipping a tool that spuriously fails on modern hardware when attempting to detect spurious hardware failures[0][1] is more of a negative than a positive. While it seems fixed in Rawhide, with a dead upstream I'm sure it's just a matter of time until it happens again (likely when the necessary GCC compat package gets dropped). 0 - https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/6TXB3XGGHFSCYVHU54HJWMDZ2NN3UAAV/ 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1811353 ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On 7/9/20 12:24 PM, Alexey A. wrote: I agree. I think that 4GB cap is too small and 4 GB may be used quickly. Since the values being used seem to have been determined somewhat heuristically for both EarlyOOM and SwapOnZRAM, I was wondering if there was any prediction for how the values might change if one, the other, or both get switched on for Server builds? SwapOnZRAM in particular is of interest to me. I have one system with a workload that's bursty on memory use, and when it starts using the swap the system becomes unresponsive, even using active SSH sessions is not guaranteed until the contention clears. The last time it happened I found myself wondering if SwapOnZRAM would make things more pleasant. It certainly does on my workstation machines, especially memory limited ones. ___ 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: The future of legacy BIOS support in Fedora.
On 7/8/20 10:47 AM, John M. Harris Jr wrote: On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote: On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: Well, if that is your concern the answer is secure boot. That will not only prevent tampering with /boot files, but also prevent tampering with the bootloader itself. No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway, needlessly disables a lot of kernel functionality, which makes it completely unusable. You cannot load kernel modules you've built, hibernate your system, etc. Additionally, Secure Boot does not prevent tampering with /boot files. You can still change grub.cfg as you like. Yet here I am, happily using it, across multiple systems... ___ 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
Swap on ZRAM thank you
I have been playing with swap on ZRAM some in the past days, and more formally running it through it's paces during today's test day[0], and I just want to say thank you to everyone involved in getting it ready for release. It has made a marked difference in desktop responsiveness when doing memory intensive tasks on memory constrained systems. It really does feel like magic. Thanks again! 0 - https://fedoraproject.org/wiki/Test_Day:F33_SwapOnZRAM ___ 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: The future of legacy BIOS support in Fedora.
On 7/2/20 3:42 PM, John M. Harris Jr wrote: GRUB2, which is a UEFI bootloader as well, is a far superior bootloader to systemd-bloat, and it supports usecases that are supported by Anaconda (the Fedora installer framework) that systemd-bloat doesn't, as addressed elsewhere in this thread by myself and several others. There is no way that supporting BIOS can be a cause for UEFI feature development being "held back". It's got nothing to do with UEFI stuff. Again with "systemd-bloat"... I guess I don't see how something that is responsible for booting the system, taking on more responsibility for booting the system, could ever be argued to be bloat? How is GRUB2 superior? I would like to see a list of pros, or alternatively, a list of things systemd-boot doesn't do. I see plenty of discussion in this thread about things not supporting UEFI, but not things that only GRUB2 can do (except boot both UEFI and BIOS machines). As for systemd-boot advantages: 1) It is simpler to configure and interact with from a running system than GRUB2 2) Supports seeding entropy generation before the Linux boot process proceeds 3) Can integrate easily with Gnome, other DEs 4) Has boot assessment, which could potentially integrate nicely with the ability to boot into a read-only recovery type mode that's been proposed[0] 5) Has hooks for automatically booting a newly installed kernel systemd-boot disadvantages: 1) No BIOS support 2) Ugly 3) Boot counting support doesn't seem real configurable? It only reverts to a previous kernel. 4) Additional testing / maintenance burden until BIOS is dropped completely 5) Limited boot entry templating ability 0 - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NZ7UVG4TA4GWNDOIUQGK3UD4B5ZUKWUJ/ ___ 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: The future of legacy BIOS support in Fedora.
On 7/2/20 3:19 PM, Martin Jackson wrote: 5-10 years? A better estimate would be 15-20 years. People aren't going to throw away perfectly fine systems and jump to new "cloud" platforms just because the OS they were using dropped BIOS support. They'll just stop updating, and likely move to something that is still supporting BIOS, if they don't write their own installer and just continue using Fedora, given that this is an entirely artificial limitation. While I completely hear you on the fact that people will often sweat assets for years longer than accounting schedules suggest they should, do you really think they're going to write custom installers??? I think it's far more likely that they would move to other distros more amenable to supporting the hardware they have. There are many distros that cater to this kind of market already, some by design and some by inclination.?? I don't think we want to drive them there. For what it's worth, I do not think that removing legacy BIOS support from Fedora is the right thing to do.?? I don't see significant benefit, and I see lots of potential harm. Thanks, Marty I don't think removing BIOS support _today_ is the right answer either. I have BIOS only hardware kicking around, and quite a bit of my UEFI hardware still supports legacy BIOS booting as well (though I don't use it). However, I'm concerned about UEFI feature development / quality assurance being held hostage by BIOS support for, based on above comments, 5 to 20 years? Surely as a somewhat leading-edge distribution, we need to start thinking about some kind of post-BIOS world. Perhaps one small step toward that future would be enabling systemd-boot on new UEFI installs, relegating GRUB2 to BIOS and upgrade installs only? This split configuration could hang around until support for GRUB2 / BIOS wanes to the point it can no longer stand under its own weight (much like 32bit install media). ___ 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: booting successfully with read-only file system
On 7/2/20 3:10 PM, Christopher Engelhard wrote: On 02.07.20 17:53, Zbigniew Jędrzejewski-Szmek wrote: It would be great if we could fairly reliably boot with a read-only root file system, all the way to the graphical environment. Obviously, such a machine will not be fully functional, but for users, debugging a disk problem when they have the normal environment with windows, tabbed terminals, graphical editors, and internet is vastly easier. It also creates an image of robustness. Imagine that instead of being rudely dropped to a terminal prompt, the user is instead able to log in as usual and see a popup like Your home directory is read-only. Do this and that. See https://... That would be fantastic, and would be miles ahead from any UX I had on any computer, ever. I hope we can all cooperate to make read-only boots nicely robust and functional. Please play with this and report bugs. I'll try to solve any that relate to systemd. The systemd version with udev.blockdev-read-only is not released yet, but is available from koji ci builds [11]. Thanks for working on this, I will definitely give it a try myself. Christopher This sounds excellent! Could we somehow provide a list of links that may be helpful to recover from certain common failures? Maybe in a MOTD? ___ 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: The future of legacy BIOS support in Fedora.
On 7/2/20 2:56 PM, John M. Harris Jr wrote: On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote: On 7/2/20 12:55 AM, John M. Harris Jr wrote: Lennart, We don't need more systemd-bloat just to boot our systems. However your bootloader works, it doesn't really matter if it's not up to snuff with GRUB2. When it supports LUKS, LVM, LUKS+LVM, a recovery console and several filesystems, then it'll be more of a viable option, and I still wouldn't recommend having yet another systemd component as a core part of our systems. At what point is systemd large enough that you'll stop adding more cruft? Can you please stop calling features of systemd you don't like "systemd-bloat" at every given opportunity? It is not being respectful to those who work on the project and doesn't help your argument. It works well with this one. It's part of systemd, for some reason. It's bloat. It's one letter off from the actual name of the software. It doesn't need to be part of systemd to integrate with it. We don't need to make our system more exclusive to make use of some systemd features, we can just use the more powerful bootloader, GRUB2, and implement what it needs to make use of these systemd "features". If your issue is with the architecture of systemd, I recommend taking an objective argument to the systemd development list. If your issue is with Fedora making use of features already implemented in systemd, I recommend making an objective argument detailing why those features shouldn't be used. If there are better alternatives that can enable Gnome is easily integrate with the bootloader (to enable say, a "Reboot to Windows" or "Reboot to UEFI" option), I would love to hear about them. I'm also interested in how further modifying GRUB2 to to enable features (that were previously bloat?) that systemd-boot supports today is better for the future of Fedora's UEFI support. Especially in regards to testing and maintenance burden. ___ 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: The future of legacy BIOS support in Fedora.
On 7/2/20 12:55 AM, John M. Harris Jr wrote: Lennart, We don't need more systemd-bloat just to boot our systems. However your bootloader works, it doesn't really matter if it's not up to snuff with GRUB2. When it supports LUKS, LVM, LUKS+LVM, a recovery console and several filesystems, then it'll be more of a viable option, and I still wouldn't recommend having yet another systemd component as a core part of our systems. At what point is systemd large enough that you'll stop adding more cruft? Can you please stop calling features of systemd you don't like "systemd-bloat" at every given opportunity? It is not being respectful to those who work on the project and doesn't help your argument. ___ 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: Previous awesome background images
On 4/20/20 11:54 AM, James Cassell wrote: On Mon, Apr 20, 2020, at 12:46 PM, Máirín Duffy wrote: On 17. 04. 20 16:07, Kamil Paral wrote: https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/ I am sad we haven't followed the pattern. (However I don't know the reasoning for stopping that.) That's not true, we didn't stop the pattern. F32 is G for Goffman. F was Fresnel. E was Elion. So on. If you dig through the tickets you'll fimd the inspiration. OMG, Secret Fedora Release Names! Did not realize it was a thing. Very cool! V/r, James Cassell Huh, I didn't realize that either. As for the original intent of this thread, I always loved the wallpaper from F15. I still have the SVG in my regular wallpaper rotation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/9/20 11:06 AM, Miroslav Lichvar wrote: On Wed, Apr 08, 2020 at 02:09:01PM -0500, Brandon Nielsen wrote: On 4/8/20 3:42 AM, Miroslav Lichvar wrote: What is the issue with using untrusted DNS servers here? An NTS client is supposed to verify the certificates. Local MITM attackers shouldn't be able to force the client to synchronize to a different NTP server. (Of course, they can always disable the synchronization.) I'm not saying there is necessarily an issue, just a logical inconsistency. If the DNS servers provided by DHCP are trusted, why would any plain NTP servers also provided by DHCP not be trusted? I can do nefarious things with either. I think it depends on the network. Is it yours or is it a random hotspot? In general neither should be trusted, but most applications don't rely on DNS being secure, so using random untrusted DNS servers from DHCP is usually not a major issue. I'm ignoring privacy issues. I disagree with saying applications don't rely on DNS being secure, but I also concede it has very little to do with this discussion. See my off-topic rant in my reply to Björn Persson. I apologize for conflating the issue in the first place. [snip] The PEERNTP option will still work. It may just have a different default and/or have a new setting. Circling back to my concerns about this proposal from an admin standpoint. I have never needed to touch PEERNTP before for DHCP provided NTP to work. I'm also not sure from a security standpoint I want `PEERNTP=yes` to work if NTS is otherwise enabled? Seems potentially confusing. I don't like chrony behavior being dictated by non-chrony config. Additionally, the 'nts' option for 'server' and 'pool' directives, to me, does not make it immediately clear that NTS will be required for _all_ NTP servers. To me, that option implies that NTS will be enforced for that particular pool or server. Especially since I can have additional directives without that option set (which admittedly makes little sense). Finally, the suggestion of bootstrapping NTP without using NTS when TLS checks fail concerns me. It needs to be clear when such a thing is allowed or not. I would be much happier with some kind of `requireents` option in `/etc/chrony.conf`. When set, NTS is an absolute hard requirement, no plain NTP servers will be used (from DHCP or otherwise), NTP bootstrapping mentioned above would also be forbidden. When not set, NTS is still verified for cases where the option is set, but other NTP servers still work (bootstrapping allowed?). Logging would help make clear what's going on, if the `nts` option is set on a pool or server with `REQUIREENTS` off, we could log warnings when non-NTS servers are used. And with `REQUIREENTS` on, we could log warnings about servers that were ignored due to not supporting NTS (including the DHCP provided one). The PEERNTP option would function as usual, not passing DHCP provided NTP servers to chrony if disabled. It would have no additional influence over chrony behavior, chrony behavior would remain entirely controlled by it's own configuration file. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/9/20 10:42 AM, Björn Persson wrote: [snip] Fedora's defaults should be chosen to keep users reasonably secure every way we can. If you as a sysadmin trust the DHCP server and every other device on the local network – including any device that may be connected in the future – then you should have the option to configure the system to trust DHCP-provided NTP and DNS servers. Björn Persson That's one part of my complaint (which, admittedly, doesn't have much to do with this proposal). We seem to be trending toward some awkward one-size-fits-some semi-trust system where parts of the network are trusted as provided, and other parts aren't. What I would love to see take shape instead (and again, I acknowledge this has almost nothing at all to to with this proposal) is the ability for users to easily mark networks as trusted or untrusted, with trusted networks using network provided resources, and the system firewall wide open (the current workstation default). On untrusted networks, DNSSEC / DoH / DoT (rough order of preference) used for DNS from a trusted resolver, NTS, firewall locked down, and maybe even a connection to a VPN automatically established if configured by the user. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/8/20 3:42 AM, Miroslav Lichvar wrote: On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote: It doesn't make much sense to me for this to default to on if we still "trust" the DNS servers provided over DHCP. What is the issue with using untrusted DNS servers here? An NTS client is supposed to verify the certificates. Local MITM attackers shouldn't be able to force the client to synchronize to a different NTP server. (Of course, they can always disable the synchronization.) I'm not saying there is necessarily an issue, just a logical inconsistency. If the DNS servers provided by DHCP are trusted, why would any plain NTP servers also provided by DHCP not be trusted? I can do nefarious things with either. Generally speaking, on a network I admin, if I've configured DHCP to provide things like NTP and DNS servers, it's because I intend client devices to use those things. While some devices choose to ignore DHCP provided DNS (and NTP), I can still reroute those requests at the edge router. Is that also possible with NTS? Even if it gets rerouted to a plain NTP server? Additionally, it's not clear to me from the proposal what it would take for an NTP server provided over DHCP to be "trusted", or what a "trusted network" is. Are only NTS-enabled sources to be trusted? Generally, yes. What I meant, if someone for example had at home a stratum 1 server (e.g. synchronized to GPS) and they trusted everything and everyone in their local network, it would make sense to still use the server (without NTS) in addition to any external time servers authenticated by NTS. The question is if we need to change the default value of the PEERNTP option. There could be a new default which adds the servers provided by DHCP only if chronyd is not using any servers with enabled authentication. That makes sense. But again, if I don't trust everything and everyone in my network, why do I trust the provided DNS servers? I feel like if this is on by default we're basically saying nobody trusts any provided NTP server unless it supports NTS. If that's the case, do away with the 'trusted network' verbiage and just say that only NTS servers provided over DHCP will be used. Additionally, what about the no-internet case? Will a local, non-NTS NTP server be acceptable in that case? I feel like that would be handled by the change to PEERNTP you mention above. But then can't attackers "disable the synchronization" as you mention above, essentially forcing us back to no additional security? Maybe what we should really have is a REQUIRENTS option for chronyd? What becomes of the old default fedora.pool.ntp.org? It would still work, even if we didn't use it by default. The name is just an alias for pool.ntp.org. The servers used in the current default configuration are not run by Fedora. Does the alias provide no additional functionality? Does it help with an estimate of running Fedora machines in the wild? Finally, from a purely personal standpoint, I don't like seeing yet more infrastructure being handed over to a hyperscaler like Cloudflare (see also DoH in Firefox). I would be less opposed to this being default if pool.ntp.org found a way to support it. Yes, that's a valid point, which we need to consider. I don't have a strong opinion either way. I'd like to see pool.ntp.org to support NTS. But I'm not sure if the trust of not being attacked will be comparable to a single entity running the servers, even if the pool has a sufficient number of NTS-enabled servers and implements some mitigations like mixing servers from different countries. Will there be some kind of 'canary domain' like there is for DoH (use-application-dns.net)? Again from a network admin standpoint, if I provide a local NTP server without NTS, I want an easy way to tell the devices I manage to use it. From a user standpoint, I like this change and the security it offers. But with a network admin hat on, it feels like yet more local infrastructure being pushed outside of my control. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/6/20 4:08 PM, Ben Cotton wrote: [snip] It doesn't make much sense to me for this to default to on if we still "trust" the DNS servers provided over DHCP. Additionally, it's not clear to me from the proposal what it would take for an NTP server provided over DHCP to be "trusted", or what a "trusted network" is. Are only NTS-enabled sources to be trusted? What becomes of the old default fedora.pool.ntp.org? Finally, from a purely personal standpoint, I don't like seeing yet more infrastructure being handed over to a hyperscaler like Cloudflare (see also DoH in Firefox). I would be less opposed to this being default if pool.ntp.org found a way to support it. ___ 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: Basic graphics mode / 'nomodeset' testing request, round 2
Desktop, UEFI, Z87 chipset, Intel Xeon E3-1230 v3, AMD R9 280X GPU - Fails, does not show the specified error instead journalctl shows: gnome-shell[1820]: Failed to create backend: No GPUs found with udev Which is likely caused by (from dmesg): [ 11.994228] [drm] VGACON disable radeon kernel modesetting. [ 11.994258] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module! On 4/8/19 8:02 PM, Adam Williamson wrote: Hi folks! A few weeks back we asked for testing of 'basic graphics mode' / nomodeset booting - the feedback from that was very helpful in establishing that we had a generic issue which dated back to Fedora 29, thanks a lot. We have now established more or less what that initial issue is, and work is ongoing to get it fixed entirely. However, it's already been fixed *partially*, and that revealed a subsequent bug. The initial bug is fixed for the case of UEFI native boots (it is not fixed for BIOS native boots yet). However, in testing, I and others found that several UEFI test systems still do not boot successfully to GDM, because they run into a *different* bug later: https://bugzilla.redhat.com/show_bug.cgi?id=1693409 This bug can be identified by the presence of the following string in the journal: "(EE) Cannot run in framebuffer mode. Please specify busIDsfor all framebuffer devices" (yes, with a bunch of spaces - but just the first part of the line is sufficient to identify the problem, I think). It would be great if folks with UEFI-capable systems could try booting a recent Fedora 30 Workstation live image on them, e.g. this one: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-30-20190408.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190408.n.0.iso ensure you boot in UEFI mode. Please report back whether it works. If it doesn't work, please check the logs - you should be able to log into a console on tty3 (ctrl-alt-f3 to get there) as root with no password, then run 'journalctl -b' to see the logs - and report if that line is present or not. If it isn't, it'd be useful to know if some other error message is present. Thanks a lot, folks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning msp430-binutils, msp430-gcc, msp430-libc, mp430mcu, and mspdebug
On 07/04/2016 06:21 PM, Rob Spanton wrote: Hi, Unfortunately I find myself having to orphan these packages: * msp430-binutils * msp430-gcc * msp430-libc * msp430mcu * mspdebug When I originally brought them into Fedora, I was doing a fair amount of msp430 firmware development. Now almost everything I do is Cortex-M based, so I don't really have any interest in maintaining these any more. Cheers, Rob -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org I've started the process of getting the new TI upstream MSP430 toolchain through package review under a new package name [1]. If someone is looking to adopt these packages, it would be great if we could work together to get them migrated to the new upstream. 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1350884 Brandon Nielsen -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introduction: Brandon Nielsen
Hi, my name is Brandon Nielsen and I've been a Fedora user since FC5. In a past career, I maintained a private yum repository for a Beowulf cluster running RHEL. I currently do some development on the TI MSP430 microcontrollers, mostly in a hobby capacity. Awhile ago I started packaging the official TI / Red Hat version of the GCC compiler for these micros, which is coincidentally a workaround to https://bugzilla.redhat.com/show_bug.cgi?id=1175942 Since I volunteered to maintain these packages in some official capacity, I have submitted a package review request: https://bugzilla.redhat.com/show_bug.cgi?id=1350884 This is my first package, so I am in need of a sponsor. You will notice I already screwed up the review request. I'll do better next time! Once this package goes through the process, I'll submit the flashing utility and the debug stack packages for review as well. Thank you for your time! Brandon Nielsen -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
