Re: Fedora Spins SIG Proposal: Fedora Mate SIG and Cinnamon SIG
I could do the testing for you. On Sat, 4 Jun 2022 at 17:01, Leigh Scott wrote: > The Cinnamon spin (kickstart and comps) are managed by Dan Book. > > https://fedoraproject.org/wiki/Changes/Cinnamon_Spin#Owner > > > I'm the only fedora developer working on Cinnamon. > I don't have any spare time to do more things including testing. > ___ > 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: Request to change default /etc/resolv.conf symlink
> Am 04.06.2022 um 15:07 schrieb Petr Menšík : > > On 04. 06. 22 12:09, Peter Boy wrote: >> Is there anywhere a kind of a list to said set of problems? Dnsmasq is >> currently the only tool that provides seamless split DNS in all (or at least >> very many) circumstances. So I’m going to change our Fedora Server >> documentation to recommend (and describe) set set up dnsmasq. > The problem with dnsmasq is it has just single upstream maintainer. Adding > new features takes time and they are also not well tested. But as its > maintainer I think it works much better than resolved. But admit it has much > worse runtime reconfiguration interface, but capable to do what is required Thanks for the info. I think this is no reason not to continue to recommend dnsmasq for Server and to refer to it in our documentation accordingly. >>> And split DNS is especially necessary when a server does host libvirt/KVM >>> VMs. In order to address its VMs (e.g. monitoring tools or forwarding >>> services) the host must query the libvirt dnsmasq instance. This is broken >>> since F34/F35 with systemd-resolved. The only reliable way i know of is a >>> second dnsmasq instance, most easily as NM plugin. > I have just started discussion about this topic in our internal tech-list. I > think there should be common interface for services, which provide any kind > of network with dynamic dns to integrate subdomain into main host cache. > Whether you use dnsmasq, unbound, systemd-resolved or knot-resolver, it > should not matter how well itegrated they can be. If the server has runtime > reconfiguration ability, there should be common way how it would allow > subdomain redirection. If you use both podman and libvirt, they should be > able to access each other via names. But that would be for entirely different > thread. A promising idea. I'm curious to read more about it. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ 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 Spins SIG Proposal: Fedora Mate SIG and Cinnamon SIG
Most things related to testing and prerelease happen in the Fedora QA team. We're just post-release for F36 so there's not a lot of visible activity, but things will be picking up again soon. https://fedoraproject.org/wiki/QA -- Chris Murphy On Sat, Jun 4, 2022, 12:04 PM Ahmed Almeleh < aalmeleh.whatever.0...@gmail.com> wrote: > I could do the testing for you. > > On Sat, 4 Jun 2022 at 17:01, Leigh Scott wrote: > >> The Cinnamon spin (kickstart and comps) are managed by Dan Book. >> >> https://fedoraproject.org/wiki/Changes/Cinnamon_Spin#Owner >> >> >> I'm the only fedora developer working on Cinnamon. >> I don't have any spare time to do more things including testing. >> ___ >> 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 > ___ 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: Review swaps
Hi, I have 2 small python packages and 1 C/C++/Qt program, but it shouldn't be too much work. btrfs-assistant https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2093585 python-axolotl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2043231 python-axolotl-curve25519 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2043228 Let me know if you'd like to swap (or do some of them)! Kind regards, Arthur fas: principis On 3/06/2022 21:46, Mark E. Fuller wrote: Dear all, I'm looking to package task (https://taskfile.dev/) for Fedora and would like to offer to swap reviews: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2078117 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2078118 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2093467 All three spec files were generated automatically and the reviews should be trivial (at least I hope so). Thanks all, fuller -- Mark E. Fuller, Ph.D. ful...@fedoraproject.org ful...@stossrohr.net @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 ___ 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 Spins SIG Proposal: Fedora Mate SIG and Cinnamon SIG
I am part of the Fedora QA team so I will see to it right away! On Sat, 4 Jun 2022 at 17:59, Chris Murphy wrote: > Most things related to testing and prerelease happen in the Fedora QA > team. We're just post-release for F36 so there's not a lot of visible > activity, but things will be picking up again soon. > > https://fedoraproject.org/wiki/QA > > > -- > Chris Murphy > > On Sat, Jun 4, 2022, 12:04 PM Ahmed Almeleh < > aalmeleh.whatever.0...@gmail.com> wrote: > >> I could do the testing for you. >> >> On Sat, 4 Jun 2022 at 17:01, Leigh Scott wrote: >> >>> The Cinnamon spin (kickstart and comps) are managed by Dan Book. >>> >>> https://fedoraproject.org/wiki/Changes/Cinnamon_Spin#Owner >>> >>> >>> I'm the only fedora developer working on Cinnamon. >>> I don't have any spare time to do more things including testing. >>> ___ >>> 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 >> > ___ > 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 Spins SIG Proposal: Fedora Mate SIG and Cinnamon SIG
The Cinnamon spin (kickstart and comps) are managed by Dan Book. https://fedoraproject.org/wiki/Changes/Cinnamon_Spin#Owner I'm the only fedora developer working on Cinnamon. I don't have any spare time to do more things including testing. ___ 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: VirtualBox and HOST kernel-5.17.12 weirdness
On 04/06/22 06:17, Ian Laurie wrote: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] (3) Xfce... if you run updates, a lot of the downloads have hashes that don't match, requiring re-download. This happens in Cinnamon also. Hi Ian. Well, just yesterday a colleague of mine showed me something very similar, but the environment was quite different from yours: * VirtualBox 6.1.4 running on Windows 10 * Ubuntu 20.04 as guest * I don't remember the Ubuntu kernel version: it should be 5.4.x but the backport repository were enabled, so I don't know it was something newer. What I've seen: * "apt update" reported a lot of hash mismatch * debsums reported some files with hash changed, but different runs showed different file. For me the problem now looks gone but I'm not sure what was the cause. I'm not a VirtualBox expert but I believe the problem stemmed from it, from one of its driver. I've updated Windows 10, updated vbox to 6.1.34 but I think that the real solution was or the guest poweroff/poweron cycle or the Windows 10 reboot. In other words I think was some VirtualBox driver misbehaving. Cesare. ___ 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: Installing ffmeg-free degrades firefox video support
Vitaly Zaitsev via devel kirjoitti 4.6.2022 klo 14.04: On 04/06/2022 00:05, Otto Urpelainen wrote: It seems clear that there is a bug somewhere, but I cannot decide, where, hence this post to devel. Should Fedora's Firefox actually have media.ffmpeg.enabled set to false by default, because Fedora's variant of ffmpeg has this problem? Should upstream Firefox be smarted about which decoder library it attempts to use? Or should ffmpeg-free package do something to avoid this from happening. Any opinions are welcome! 1. Enable RPM Fusion repository. 2. sudo dnf install ffmpeg-libs --allowerasing Sure, RPM Fusion's ffmpeg does not suffer from this problem. But the question is, what needs to be done so that ffmpeg-free will not suffer, either. ___ 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
Need help with bodhi pushing failure
Hi, I encountered a pushing failure after editing a update from side-tag, bodhi says FEDORA-2022-a0a90518a0 ejected from the push because "Cannot find relevant tag for fcitx5-5.0.17-1.fc36. None of ['f36-build-side-53961'] are in [... lot of tags ...] Related update is https://bodhi.fedoraproject.org/updates/FEDORA-2022-a0a90518a0 Could anyone help me pushing this update to testing/stable? Cheers, Qiyu -- Qiyu Yan GPG keyid: 0x4FC914F065F2DF12 About: https://fedoraproject.org/wiki/User:Yanqiyu signature.asc Description: This is a digitally signed message part ___ 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: Installing ffmeg-free degrades firefox video support
On 04/06/2022 00:05, Otto Urpelainen wrote: It seems clear that there is a bug somewhere, but I cannot decide, where, hence this post to devel. Should Fedora's Firefox actually have media.ffmpeg.enabled set to false by default, because Fedora's variant of ffmpeg has this problem? Should upstream Firefox be smarted about which decoder library it attempts to use? Or should ffmpeg-free package do something to avoid this from happening. Any opinions are welcome! 1. Enable RPM Fusion repository. 2. sudo dnf install ffmpeg-libs --allowerasing -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Installing ffmeg-free degrades firefox video support
I could try that I just happened to have tested Firefox updates on Fedora 35 and 36, today and yesterday. I encountered problems with media playback even with openh264 enabled. I will let you know if it fixes the audio issue as well. On Sat, 4 Jun 2022 at 12:05, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 04/06/2022 00:05, Otto Urpelainen wrote: > > It seems clear that there is a bug somewhere, but I cannot decide, > > where, hence this post to devel. Should Fedora's Firefox actually have > > media.ffmpeg.enabled set to false by default, because Fedora's variant > > of ffmpeg has this problem? Should upstream Firefox be smarted about > > which decoder library it attempts to use? Or should ffmpeg-free package > > do something to avoid this from happening. Any opinions are welcome! > > 1. Enable RPM Fusion repository. > 2. sudo dnf install ffmpeg-libs --allowerasing > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > 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
Fedora Spins SIG Proposal: Fedora Mate SIG and Cinnamon SIG
Hello, I have been a fan of the Mate-Compiz and Cinnamon desktops for a while now. And I am aware that the "Mate-Compiz" and "Cinnamon" spins are available. However, I feel more should be done with it for example: testing and developing and supporting it's growth. Open to any opinions / comments regarding my proposals . Thanks, Ahmed Almeleh He / Him / His Fedora QA Contributor. ___ 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: Request to change default /etc/resolv.conf symlink
On 04. 06. 22 12:23, Michael Catanzaro wrote: No, I have no clue. But I'm pretty sure applications that do choose to use /etc/resolv.conf still deserve to receive correct results. Agreed. Which they do not receive from systemd-resolved in certain use cases. Applications use DNS because they expect fully working DNS. Yet systemd adds several non-standard "improvements", which breaks other use cases. I would not complain if it just worked. I see Lennart responded in the upstream bug: https://github.com/systemd/systemd/issues/19227 although it's still waiting on him after a long time. This is an upstream issue, not a downstream issue, so I wouldn't expect much interaction in the downstream bug report. Michael This is an existing issue in Fedora installation. So I fill bugs to Fedora. It is up to fedora maintainers to forward those reports to upstream, if it affects also upstream, or at least we it that way in our team. I don't want to join systemd development. The reason I fill issues there is to improve name resolution in Fedora and also RHEL. Because filled bugzillas have no effect, I try at least on github. To have at least evidence those issues were known and reported. But unlike Fedora, there is no ON_QA phase. They implement something and close the bug. Often it makes me to report another issue, because that was not what were requested or just half of the problem were fixed. Just like with the bug you have mentioned. We have a workflow for that in bugzilla, but it is not used on upstream. -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Request to change default /etc/resolv.conf symlink
On 04. 06. 22 12:09, Peter Boy wrote: Is there anywhere a kind of a list to said set of problems? Dnsmasq is currently the only tool that provides seamless split DNS in all (or at least very many) circumstances. So I’m going to change our Fedora Server documentation to recommend (and describe) set set up dnsmasq. The problem with dnsmasq is it has just single upstream maintainer. Adding new features takes time and they are also not well tested. But as its maintainer I think it works much better than resolved. But admit it has much worse runtime reconfiguration interface, but capable to do what is required. That may be true for enterprise usage. For the large number of private stand alone server or SME servers DNSSEC is not more important as for desktops. Depends. Servers often produce much more queries, which would have higher impact if cache were poisoned. DNSSEC protects against that. Unlike weird networks laptop can be connected to, which does not pass required DNSSEC records, data centers usually provide perfect service including fully working DNSSEC. There should not be often reason to turn it off. And split DNS is especially necessary when a server does host libvirt/KVM VMs. In order to address its VMs (e.g. monitoring tools or forwarding services) the host must query the libvirt dnsmasq instance. This is broken since F34/F35 with systemd-resolved. The only reliable way i know of is a second dnsmasq instance, most easily as NM plugin. I have just started discussion about this topic in our internal tech-list. I think there should be common interface for services, which provide any kind of network with dynamic dns to integrate subdomain into main host cache. Whether you use dnsmasq, unbound, systemd-resolved or knot-resolver, it should not matter how well itegrated they can be. If the server has runtime reconfiguration ability, there should be common way how it would allow subdomain redirection. If you use both podman and libvirt, they should be able to access each other via names. But that would be for entirely different thread. So we need a way to configure DNS resolution based on custom needs in every single case, at least until systemd-resolved has resolved all the issues (it is a very nice and elegant solution, I think) Wouldn’t be systemd-resolvd in enabled or disabled state a valid indicator what a sysadmin want’s to use and whether to replace a resolv.conf file by a symbolic link or vice versa? -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure I have filled attempt to improve situation with /etc/resolv.conf ownership in PR [1], but it were not accepted well. I think resolved takes over /etc/resolv.conf even in case where it should not. If you disable systemd-resolved, it leaves your system without working resolution. Even reboot would not fix it automatically. It is fine to have /etc/resolv.conf missing in some cases, but that is not supported by resolved. 1. https://github.com/systemd/systemd/pull/21317 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Request to change default /etc/resolv.conf symlink
> Am 04.06.2022 um 12:33 schrieb Michael Catanzaro : > > On Sat, Jun 4 2022 at 12:09:00 PM +0200, Peter Boy wrote: >> And split DNS is especially necessary when a server does host libvirt/KVM >> VMs. In order to address its VMs (e.g. monitoring tools or forwarding >> services) the host must query the libvirt dnsmasq instance. This is broken >> since F34/F35 with systemd-resolved. The only reliable way i know of is a >> second dnsmasq instance, most easily as NM plugin. > > Does running dnsmasq alongside systemd-resolved have many advantages over > just switching to dnsmasq altogether? I would consider that instead. Well, originally we wanted to configure Fedora Server as close to Fedora decided defaults as possible. And Fedora decided systemd-resolved to be the default DNS resolution for F33 and newer. Because libvirt and systemd-resolved don’t cooperate, you need to use a libvirt hook to call resolvectl and configure the libvirt virbr0 interface and name server for the VMs network. As long as that worked, the configuration was as close to Fedora defaults as possible and it worked nice. Pre F33 we recommended to use the libvirt provided dnsmasq for the internal network and to activate NM dnsmasq plugin as an additional instance used by the host. That instance configuration used the libvirt dnsmasq to resolve the internal VM network and forwarded everything else to the NM configured external DNS server (i.e. split DNS). And provides DNS caching. And now we are back there again and completely disable systemd-resolved. Therefore I asked for the list of known weaknesses of dnsmasq Peter Mensik mentioned. >> Wouldn’t be systemd-resolvd in enabled or disabled state a valid indicator >> what a sysadmin want’s to use and whether to replace a resolv.conf file by a >> symbolic link or vice versa? > > It's actually the opposite: how you have configured /etc/resolv.conf tells > NetworkManager how you want to manage DNS, if you have no manual > NetworkManager configuration specified. But you can edit NetworkManager > configuration to choose whatever behavior you want. You want dns=dnsmasq: > > https://wiki.gnome.org/Projects/NetworkManager/DNS Wasn’t the initial issue that every dnf update replaces the locally configured resolv.conf file by a symbolic link and so crashes the local configuration? So, could an update make an replacement dependent on an enabled and active systemd-resolved service? Or am I just confusing this with another thread? (Sorry in that case) -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ 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
Fedora-Cloud-34-20220604.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220603.0): ID: 1288838 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1288838 ID: 1288846 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1288846 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Request to change default /etc/resolv.conf symlink
> Am 04.06.2022 um 04:07 schrieb Petr Menšík : > > ... > On 04. 06. 22 2:56, Michael Catanzaro wrote: >> >> Hi, >> >> ... > I admit dnsmasq, which I maintain, has existing integration with NM, which > can provide required functionality. It has its own set of problems however, > therefore I am not pushing it as a replacement in general. Is there anywhere a kind of a list to said set of problems? Dnsmasq is currently the only tool that provides seamless split DNS in all (or at least very many) circumstances. So I’m going to change our Fedora Server documentation to recommend (and describe) set set up dnsmasq. >> For servers, the opposite is generally true: DNSSEC is generally way more >> important than split DNS. Of course, there will be exceptions -- e.g. you're >> familiar with cases where DNSSEC is needed on desktops, and servers on some >> complex networks apparently really do require split DNS -- but it's true as >> a generalization. So if we are forced to choose between working split DNS >> vs. working DNSSEC, I would pick the split DNS for desktop editions, and >> DNSSEC for server editions. (On servers, the main benefit of >> systemd-resolved is the DNS cache.) > Sure, I admit servers need DNSSEC more and are actually able to use it > already. Also tend to use more often more advanced DNS caches. That may be true for enterprise usage. For the large number of private stand alone server or SME servers DNSSEC is not more important as for desktops. And split DNS is especially necessary when a server does host libvirt/KVM VMs. In order to address its VMs (e.g. monitoring tools or forwarding services) the host must query the libvirt dnsmasq instance. This is broken since F34/F35 with systemd-resolved. The only reliable way i know of is a second dnsmasq instance, most easily as NM plugin. So we need a way to configure DNS resolution based on custom needs in every single case, at least until systemd-resolved has resolved all the issues (it is a very nice and elegant solution, I think) Wouldn’t be systemd-resolvd in enabled or disabled state a valid indicator what a sysadmin want’s to use and whether to replace a resolv.conf file by a symbolic link or vice versa? -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ 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: Request to change default /etc/resolv.conf symlink
On Sat, Jun 4 2022 at 04:07:09 AM +0200, Petr Menšík wrote: Do we have any list of significant applications, which use /etc/resolv.conf only? It is used by most of DNS related tools I manage. dig and host use dns only. Sure, they would not be able to report split-DNS required hosts correctly. But browsers tend to use getaddrinfo() glibc calls AFAIK. Can you name some important? No, I have no clue. But I'm pretty sure applications that do choose to use /etc/resolv.conf still deserve to receive correct results. On Sat, Jun 4 2022 at 04:07:09 AM +0200, Petr Menšík wrote: Well, I had not reopened that bug only because it were slight improvement. But I wanted it working in default configuration, which is requested explicitly: https://bugzilla.redhat.com/show_bug.cgi?id=1945309 You and I have exchanged few comments, but maintainers never wrote a single line. What I would have a tracker for, when those bugs don't receive a single comment after 6 months? I don't keep bitting by resolved only because I always disable it ASAP on my machines. I report every issue I find, but very little of them have any progress. I see Lennart responded in the upstream bug: https://github.com/systemd/systemd/issues/19227 although it's still waiting on him after a long time. This is an upstream issue, not a downstream issue, so I wouldn't expect much interaction in the downstream bug report. Michael ___ 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: Archive value is out of time_t range
https://bugzilla.redhat.com/show_bug.cgi?id=2092964 On 6/2/22 17:46, Petr Pisar wrote: I recommend you to file a bug against tar in Fedora's Bugzilla. However, this proposed solution would require rebuilding in the same way all libraries which tar uses and which pass time_t and similar types in their interface. That would probably break other packages. So maybe more realisic fix will enhancing tar to ignore these time stamps when unpacking an archive. -- Petr ___ 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 -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/ OpenPGP_0xCC1CFEF30920C8AE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Request to change default /etc/resolv.conf symlink
On Sat, Jun 4 2022 at 12:09:00 PM +0200, Peter Boy wrote: And split DNS is especially necessary when a server does host libvirt/KVM VMs. In order to address its VMs (e.g. monitoring tools or forwarding services) the host must query the libvirt dnsmasq instance. This is broken since F34/F35 with systemd-resolved. The only reliable way i know of is a second dnsmasq instance, most easily as NM plugin. Does running dnsmasq alongside systemd-resolved have many advantages over just switching to dnsmasq altogether? I would consider that instead. Wouldn’t be systemd-resolvd in enabled or disabled state a valid indicator what a sysadmin want’s to use and whether to replace a resolv.conf file by a symbolic link or vice versa? It's actually the opposite: how you have configured /etc/resolv.conf tells NetworkManager how you want to manage DNS, if you have no manual NetworkManager configuration specified. But you can edit NetworkManager configuration to choose whatever behavior you want. You want dns=dnsmasq: https://wiki.gnome.org/Projects/NetworkManager/DNS Michael ___ 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
Fedora-Cloud-36-20220604.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-36-20220603.0): ID: 1288822 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1288822 ID: 1288830 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1288830 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Updated criteria proposal: networking requirements
Sounds good to me. On Sat, 4 Jun 2022, 01:25 Michael Catanzaro, wrote: > On Fri, Jun 3 2022 at 04:35:41 PM -0700, Adam Williamson > wrote: > > Using the default network configuration tools for the console and for > > release-blocking desktops, it must be possible to establish a working > > connection to common OpenVPN, openconnect-supported and vpnc-supported > > VPN servers with typical configurations. > > I would add Wireguard too, plus a limitation that the criterion only > applies if the desktop ships with support for these protocols. > > ___ > 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
[EPEL-devel] Thoughts: epel-release auto-enable crb repo
When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it. The more I think about it, the more I think we shouldn't auto-enable the crb repo for epel8 and epel9. Here are my reasons why. 1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation. 2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't own. 3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb. 4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts. I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. But I also wanted to get others' thoughts before I close the bug and pull request. What do others think? Troy [1] - https://pagure.io/epel/issue/128 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Sat, Jun 4, 2022 at 8:52 PM Troy Dawson wrote: > What do others think? Almost everything *I* care to do with el eventually needs epel and/or CRB/Powertools. I also do not think CRB/Powertools should be auto-enabled by epel (epel does not own them, and should not touch them). And, yes, a couple of my ansible scripts do enable epel and crb/powertools in order to install packages, but that is my choice, not someone else's. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson wrote: > > When I first created the EPEL issue to auto-enable crb repo[1] I was only > thinking of CAN we do it. I wasn't thinking SHOULD we do it. > We've come to the point that we actually can do it. But before we go down > that road, I wanted to take a step back and ask, should we do it. > > The more I think about it, the more I think we shouldn't auto-enable the crb > repo for epel8 and epel9. Here are my reasons why. > > 1 - The need to auto-enable crb isn't as big as it was before. > At the time that I wrote that issue, I was getting quite alot of bugs / pings > / emails about epel packages not being installable. I think on average > about 2 a month. > With epel being in fedora-docs, and with Carl's re-write of how to enable > epel, that number has dropped significantly. I possibly still average one a > month, but that's an average over a year, with most of them being last year. > In short, I believe the documentation is better, and easier to find, allowing > people to enable crb on their own, without automation. > > 2 - crb isn't an epel repo > We really shouldn't be messing with other repo's that we, epel, don't own. > > 3 - We are taking the choice away from users > After I stopped and thought about it, there are plenty of scenarios where > people want epel for just one or two packages, which do not require crb. > > 4 - All the many small side cases. > auto-enabling crb will have bugs. RHEL and it's clones are in too many odd > places for us to not hit some odd use cases we didn't expect. We'd have to > keep fixing the scripts. > > I could go into more explanation on each of those things, but in the end, > I've talked myself out of wanting to auto-enable crb for epel8 and epel9. > But I also wanted to get others' thoughts before I close the bug and pull > request. > > What do others think? > Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies. I get variations of these two examples at least *once a month*. Sometimes even filed as Bugzilla reports. It takes time away from me doing normal work. I can easily imagine other contributors having similar burdens. For me, this is absolutely an annoying issue that creates enough overhead to be worth fixing. Once you get to this level, "crb isn't an epel repo" and "we are taking the choice away from users" is silly, because we absolutely depend on crb being enabled and users don't know how we cross into RHEL repos for dependencies. Heck, many packagers building for EPEL don't. Even worse, some RHEL folks don't realize how difficult it is to use RHEL without CRB. The worst thing that could happen with auto-enabling is that it fails to run. We can easily just put some output when it fails to tell users that CRB/PowerTools could not be auto-enabled and for users to ensure it's enabled. But *not* attempting to auto-enable it means we accept that RHEL's bad choices on this are impossible to work around. It would be more tolerable if CentOS Stream had CRB content available by default like how CentOS Linux 7 has the content from the RHEL 7 optional channel available by default. Sadly, every attempt to make that happen has failed. Thus, CentOS Stream and RHEL clones (which are effectively clones of CentOS Stream) don't do it, so we have a usability problem that causes pain for contributors and users. To be crystal clear, I would like this fixed for at least the majority of cases and gracefully fail when it can't be fixed. -- 真実はいつも一つ！/ Always, there's only one truth! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On 6/5/22 03:47, Stephen Smoogen wrote: On Sat, 4 Jun 2022 at 18:54, Neal Gompa wrote: On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson wrote: > > When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. > We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it. > > The more I think about it, the more I think we shouldn't auto-enable the crb repo for epel8 and epel9. Here are my reasons why. > > 1 - The need to auto-enable crb isn't as big as it was before. > At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. > With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. > In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation. > > 2 - crb isn't an epel repo > We really shouldn't be messing with other repo's that we, epel, don't own. > > 3 - We are taking the choice away from users > After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb. > > 4 - All the many small side cases. > auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts. > > I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. > But I also wanted to get others' thoughts before I close the bug and pull request. > > What do others think? > Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies. To be crystal clear, I would like this fixed for at least the majority of cases and gracefully fail when it can't be fixed. The issue is going to be that an RPM which changes outside subscriptions will probably be an auditable finding for a lot of sites. It is one of the reasons this has been considered bad form in the past and would probably cause a lot of requests that it be made optional, removed, OR epel black listed. It doesn't matter if we all think that would be a silly finding, changes like this are considered security issues at various sites especially if for the last 15 years, epel-release has not done something like that and so had been 'approved' for use. At best I could see an optional side package `epel-release-enable-other-repo` or some similar name which just has these changes and is not pulled in by default and requires epel-release. Thus you could tell people to install `epel-release-enable-crb` and would get packages and if people have reports of broken packages you tell them to install this which will do the correct repo changes. I really do not want to bash anyone but for _ages_ and I really mean a long long time, Ubuntu and Debian know how to be friendly and fail gracefully, suggesting the exact command that must be used when a package fails to get installed because it is not found. It's not like it is so hard to tell the user to run "dnfconfig-manager --set-enabled $whateverrepoisneeded" or even better continue with " Do you want me to enable it for you now ?" wolfy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following builds have been pushed to Fedora EPEL 7 updates-testing tio-1.38-1.el7 Details about builds: tio-1.38-1.el7 (FEDORA-EPEL-2022-a9dcbb8f45) Simple TTY terminal I/O application Update Information: # tio v1.38* Redirect error messages to stderr* Improve help and man page* Mention config file in `--help`* Fix running without config file * Fix config file error messages* Redirect error messages to stderr* Add repology packaging status* Fix parsing of default settings Default configuration file settings were not parsed in case a section was matched. Now we make sure that the default (unnamed) settings are always parsed.* Append to existing log file (no truncation)* Add socket info to show configuration * Print socket info at startup* Fix socket option parsing* Match user input against config section names if pattern matching was unsuccessful. This allows for better config file ergonomics if the user has a diverse set of serial devices as the name does not need to be specified in the config file twice.* Add support for external control via a Unix domain socket. This feature allows an external program to inject output into and listen to input from a serial port via a Unix domain socket (path specified via the `-S`/`--socket` command line flag, or the socket config file option) while tio is running. This is useful for ad-hoc scripting of serial port interactions while still permitting manual control. Since many serial devices (at least on Linux) get confused when opened by multiple processes, and most commands do not know how to correctly open a serial device, this allows a more convenient usage model than directly writing to the device node from an external program. Any input from clients connected to the socket is sent on the serial port as if entered at the terminal where tio is running (except that `ctrl-t` sequences are not recognized), and any input from the serial port is multiplexed to the terminal and all connected clients. Sockets remain open while the serial port is disconnected, and writes will block. Example usage 1 (issue a command): `echo command | nc -UN /path/to/socket > /dev/null` Example usage 2 (use the expect command to script an interaction): ``` #!/usr/bin/expect -f set timeout -1 log_user 0 spawn nc -UN /path/to/socket set uart $spawn_id send -i $uart "command1\n" expect -i $uart "prompt> " send -i $uart "command2\n" expect -i $uart "prompt> " ```* fix for using option `log` without `log- filename` in config file ChangeLog: * Sat Jun 4 2022 Robert Scheck 1.38-1 - Upgrade to 1.38 (#2092955) References: [ 1 ] Bug #2092955 - tio-1.38 is available https://bugzilla.redhat.com/show_bug.cgi?id=2092955 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Sat, 4 Jun 2022 at 18:54, Neal Gompa wrote: > On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson wrote: > > > > When I first created the EPEL issue to auto-enable crb repo[1] I was > only thinking of CAN we do it. I wasn't thinking SHOULD we do it. > > We've come to the point that we actually can do it. But before we go > down that road, I wanted to take a step back and ask, should we do it. > > > > The more I think about it, the more I think we shouldn't auto-enable the > crb repo for epel8 and epel9. Here are my reasons why. > > > > 1 - The need to auto-enable crb isn't as big as it was before. > > At the time that I wrote that issue, I was getting quite alot of bugs / > pings / emails about epel packages not being installable. I think on > average about 2 a month. > > With epel being in fedora-docs, and with Carl's re-write of how to > enable epel, that number has dropped significantly. I possibly still > average one a month, but that's an average over a year, with most of them > being last year. > > In short, I believe the documentation is better, and easier to find, > allowing people to enable crb on their own, without automation. > > > > 2 - crb isn't an epel repo > > We really shouldn't be messing with other repo's that we, epel, don't > own. > > > > 3 - We are taking the choice away from users > > After I stopped and thought about it, there are plenty of scenarios > where people want epel for just one or two packages, which do not require > crb. > > > > 4 - All the many small side cases. > > auto-enabling crb will have bugs. RHEL and it's clones are in too many > odd places for us to not hit some odd use cases we didn't expect. We'd > have to keep fixing the scripts. > > > > I could go into more explanation on each of those things, but in the > end, I've talked myself out of wanting to auto-enable crb for epel8 and > epel9. > > But I also wanted to get others' thoughts before I close the bug and > pull request. > > > > What do others think? > > > > Let me start with examples that I get *regularly*: Pagure fails to > install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is > not available. KDE Plasma fails to install because of a mass of > missing dependencies. > > > To be crystal clear, I would like this fixed for at least the majority > of cases and gracefully fail when it can't be fixed. > > The issue is going to be that an RPM which changes outside subscriptions will probably be an auditable finding for a lot of sites. It is one of the reasons this has been considered bad form in the past and would probably cause a lot of requests that it be made optional, removed, OR epel black listed. It doesn't matter if we all think that would be a silly finding, changes like this are considered security issues at various sites especially if for the last 15 years, epel-release has not done something like that and so had been 'approved' for use. At best I could see an optional side package `epel-release-enable-other-repo` or some similar name which just has these changes and is not pulled in by default and requires epel-release. Thus you could tell people to install `epel-release-enable-crb` and would get packages and if people have reports of broken packages you tell them to install this which will do the correct repo changes. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2091256] perl-Module-CoreList-5.20220527 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2091256 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Module-CoreList-5.2022 ||0527-1.fc36 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2022-06-05 01:09:36 --- Comment #5 from Fedora Update System --- FEDORA-2022-3a6d995044 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2091256 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2093567] New: perl-Math-NumSeq-75 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2093567 Bug ID: 2093567 Summary: perl-Math-NumSeq-75 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Math-NumSeq Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 75 Upstream release that is considered latest: 75 Current version/release in rawhide: 74-10.fc37 URL: http://search.cpan.org/dist/Math-NumSeq/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3062/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Math-NumSeq -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2093567 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
