Re: Fedora 33 System-Wide Change proposal: systemd-resolved
* John M. Harris, Jr.: > On Tuesday, September 1, 2020 5:19:15 AM MST Florian Weimer wrote: >> * John M. Harris, Jr.: >> >> >> > Sure, those two companies will be thrilled, I'm sure. This is a huge >> > disservice to our users. Why in the world does systemd try to force DNS >> > servers when none are configured? If no DNS servers are configured, there >> > >> > should be no DNS servers in use. >> >> >> Acutally, the historic default is to use localhost (127.0.0.1). This is >> what an empty or missing /etc/resolv.conf file has always meant. >> >> (Okay, there was apparently a time when localhost could also be reached >> at 0.0.0.0, and that was the default before 127.0.0.1. But that likely >> predates the Linux networking stack.) > > Well, that was only reading host files, right? Or do you mean the > system would actually perform lookup against itself? It actually sends UDP packets to 127.0.0.1, port 53. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Release criteria proposal: first boot experience
On Tue, Sep 1, 2020, 11:11 PM Bruno Wolff III wrote: > On Tue, Sep 01, 2020 at 22:09:57 -0600, > Chris Murphy wrote: > >On Tue, Sep 1, 2020 at 8:16 PM John M. Harris Jr > wrote: > >> > > > >You're using net installer? The Live doesn't have user configuration > >in the installer. > > I did some live installs last week of rawhide and was able to create one > user account in the installer. You need to do either that or set up > root. Though you can do both. It might be different in F33. > No user creation in Workstation Live, for a long time. First user is created by GNOME Initial Setup. Root user is not enabled. -- Chris Murphy > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Release criteria proposal: first boot experience
On Tue, Sep 01, 2020 at 22:09:57 -0600, Chris Murphy wrote: On Tue, Sep 1, 2020 at 8:16 PM John M. Harris Jr wrote: You're using net installer? The Live doesn't have user configuration in the installer. I did some live installs last week of rawhide and was able to create one user account in the installer. You need to do either that or set up root. Though you can do both. It might be different in F33. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Release criteria proposal: first boot experience
On Tue, Sep 1, 2020 at 8:16 PM John M. Harris Jr wrote: > > On Tuesday, September 1, 2020 1:22:26 PM MST Michael Catanzaro wrote: > > Hi, > > > > We currently have a bug where the Online Accounts page in initial setup > > is nonfunctional. [1] This doesn't violate any current release > > criterion, but surely we don't want to release with a broken initial > > setup experience. So let's add a new requirement for that. How about > > something like: > > > > "If an initial setup utility is run or intended to be run after the > > first boot of the installed system, then it must start successfully and > > each page or panel of the initial setup utility should withstand a > > basic functionality test." > > > > OK that's pretty basic, but it gets the point across. I think this can > > be a final requirement, not necessarily important enough to be a beta > > requirement. Bikeshed away! > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476 > > I would like to report a bug with the first boot experience: > > Upon installing a new GNOME system, I'm accosted with a dialog asking me > questions about the system I just finished configuring in Anaconda. You're using net installer? The Live doesn't have user configuration in the installer. >Is there > something in Anaconda I'm missing to disable this behavior, or do I have to > write my own kickstart to fix that? Probably still works... https://blog.centos.org/2013/12/preventing-gnome3s-initial-setup/ -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 2020-09-02 11:00, Neal Gompa wrote: > On Tue, Sep 1, 2020 at 10:51 PM Nico Kadel-Garcia wrote: >> On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr >> wrote: >>> On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote: On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr wrote: > Michael, > > The file is /etc/nsswitch.conf. You're wasting everyone's time with these low-effort spam posts. >>> I don't see how this could possibly be spam. This is where the file is, is >>> it >>> not? >>> Lest anyone become confused, there is a big warning at the top of that file warning you that it is managed by authselect, and that manual changes will be overwritten. >>> I don't know what you're talking about here. Am I missing something? Is >>> this a >>> F33 Change? Exact content of my /etc/nsswitch: >> Stated in the file or not, it is in fact edited by authconfig, >> sometimes as part of RPM installation. Manual editing of it is not and >> has never been stable without setting up some kind of configuration >> management to restore RPM based modifications. Been there, done that, >> with one of those 10-year solo admins who decided to hand-edit tweaks >> but refused to permit management of the file. >> >> And oh, "files" always comes first because local config files should >> always take priority over upstream network based services. > authconfig is dead. But yes, nsswitch is managed by authselect. > I would state that slightly differently. nsswitch.conf is now managed by authselect by default. I say that since, as I've already mentioned, I have a F32 system which has been upgraded over time from versions without authselect. The upgrade didn't changed that. So, to become more conforming to current practice I did just run... authselect select --force sssd -- The key to getting good answers is to ask good questions. ___ 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 System-Wide Change proposal: systemd-resolved
On 2020-09-02 11:06, John M. Harris Jr wrote: > On Tuesday, September 1, 2020 7:29:44 PM MST Ed Greshko wrote: >> On 2020-09-02 10:21, John M. Harris Jr wrote: >> >>> I don't know what you're talking about here. Am I missing something? Is >>> this a F33 Change? Exact content of my /etc/nsswitch: >> >> Is your system an upgrade of an earlier version? >> >> In my case I have an F32 system which has been around for a few years. It >> has the text you cite. > >> I also have an F32 system which was a fresh install as well as a F31 fresh >> install. Both have > >> # Generated by authselect on Fri Jul 31 09:40:00 2020 >> # Do not modify this file manually. >> >> # If you want to make changes to nsswitch.conf please modify >> # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'. >> >> In /etc/nsswitch.conf. So, the default use of authselect has been around >> since at least F31. > My system was originally F24. So, which of these is the actual configuration > file at this point? > Upgrades didn't change how things are done. I think it may have been F29 or F30 when authselect was introduced and made the default method to manage nsswitch.conf. FWIW, on this old system of mine I did just run authselect select --force sssd to bring it forward to the current practice. -- The key to getting good answers is to ask good questions. ___ 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 System-Wide Change proposal: systemd-resolved
On Tuesday, September 1, 2020 7:29:44 PM MST Ed Greshko wrote: > On 2020-09-02 10:21, John M. Harris Jr wrote: > > > I don't know what you're talking about here. Am I missing something? Is > > this a F33 Change? Exact content of my /etc/nsswitch: > > > Is your system an upgrade of an earlier version? > > In my case I have an F32 system which has been around for a few years. It > has the text you cite. > I also have an F32 system which was a fresh install as well as a F31 fresh > install. Both have > # Generated by authselect on Fri Jul 31 09:40:00 2020 > # Do not modify this file manually. > > # If you want to make changes to nsswitch.conf please modify > # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'. > > In /etc/nsswitch.conf. So, the default use of authselect has been around > since at least F31. My system was originally F24. So, which of these is the actual configuration file at this point? -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Tue, Sep 1, 2020 at 10:51 PM Nico Kadel-Garcia wrote: > > On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr > wrote: > > > > On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote: > > > On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr > > > wrote: > > > > > > > Michael, > > > > > > > > The file is /etc/nsswitch.conf. > > > > > > > > > You're wasting everyone's time with these low-effort spam posts. > > > > I don't see how this could possibly be spam. This is where the file is, is > > it > > not? > > > > > Lest anyone become confused, there is a big warning at the top of that > > > file > > > warning you that it is managed by authselect, and that manual changes > > > will be overwritten. > > > > I don't know what you're talking about here. Am I missing something? Is > > this a > > F33 Change? Exact content of my /etc/nsswitch: > > Stated in the file or not, it is in fact edited by authconfig, > sometimes as part of RPM installation. Manual editing of it is not and > has never been stable without setting up some kind of configuration > management to restore RPM based modifications. Been there, done that, > with one of those 10-year solo admins who decided to hand-edit tweaks > but refused to permit management of the file. > > And oh, "files" always comes first because local config files should > always take priority over upstream network based services. authconfig is dead. But yes, nsswitch is managed by authselect. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr wrote: > > On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote: > > On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr > > wrote: > > > > > Michael, > > > > > > The file is /etc/nsswitch.conf. > > > > > > You're wasting everyone's time with these low-effort spam posts. > > I don't see how this could possibly be spam. This is where the file is, is it > not? > > > Lest anyone become confused, there is a big warning at the top of that file > > warning you that it is managed by authselect, and that manual changes > > will be overwritten. > > I don't know what you're talking about here. Am I missing something? Is this a > F33 Change? Exact content of my /etc/nsswitch: Stated in the file or not, it is in fact edited by authconfig, sometimes as part of RPM installation. Manual editing of it is not and has never been stable without setting up some kind of configuration management to restore RPM based modifications. Been there, done that, with one of those 10-year solo admins who decided to hand-edit tweaks but refused to permit management of the file. And oh, "files" always comes first because local config files should always take priority over upstream network based services. ___ 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 System-Wide Change proposal: systemd-resolved
On 2020-09-02 10:21, John M. Harris Jr wrote: > I don't know what you're talking about here. Am I missing something? Is this > a > F33 Change? Exact content of my /etc/nsswitch: Is your system an upgrade of an earlier version? In my case I have an F32 system which has been around for a few years. It has the text you cite. I also have an F32 system which was a fresh install as well as a F31 fresh install. Both have # Generated by authselect on Fri Jul 31 09:40:00 2020 # Do not modify this file manually. # If you want to make changes to nsswitch.conf please modify # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'. In /etc/nsswitch.conf. So, the default use of authselect has been around since at least F31. -- The key to getting good answers is to ask good questions. ___ 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 System-Wide Change proposal: systemd-resolved
On Tuesday, September 1, 2020 5:19:15 AM MST Florian Weimer wrote: > * John M. Harris, Jr.: > > > > Sure, those two companies will be thrilled, I'm sure. This is a huge > > disservice to our users. Why in the world does systemd try to force DNS > > servers when none are configured? If no DNS servers are configured, there > > > > should be no DNS servers in use. > > > Acutally, the historic default is to use localhost (127.0.0.1). This is > what an empty or missing /etc/resolv.conf file has always meant. > > (Okay, there was apparently a time when localhost could also be reached > at 0.0.0.0, and that was the default before 127.0.0.1. But that likely > predates the Linux networking stack.) Well, that was only reading host files, right? Or do you mean the system would actually perform lookup against itself? -- John M. Harris, Jr. Splentity ___ 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 System-Wide Change proposal: systemd-resolved
On Tuesday, September 1, 2020 7:22:49 AM MST Michael Catanzaro wrote: > On Tue, Sep 1, 2020 at 8:17 am, Nico Kadel-Garcia > wrote: > > > Hiding it inside yet another systemd structure without following the > > existing standards is, sadly, typical of systemd. It also puts at risk > > restricted environments where providing no DNS is deliberately used to > > restrict outbound network use, such as virtual machines or chroot > > cages without an enabled /etc/resolv.conf. That includes the "mock" > > build environment where "pip install" is kept network disabled by the > > lack of DNS. > > > So open up /etc/systemd/resolved.conf and set FallbackDNS= (set it to > nothing). That will override fallback to Cloudflare or Google. Then > you're done. This is not something that any user should ever have to do. If there are no configured DNS servers, either by DHCP or manual configuration, the user doesn't want DNS. > Realistically, this fallback is unlikely to ever be used anyway, so it > doesn't matter very much. And if you're operating a restricted > environment and you don't know how to configure DNS, you likely have > bigger problems than systemd If this is unlikely to be used, can we get this set to empty by default in Fedora? -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote: > On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr > wrote: > > > Michael, > > > > The file is /etc/nsswitch.conf. > > > You're wasting everyone's time with these low-effort spam posts. I don't see how this could possibly be spam. This is where the file is, is it not? > Lest anyone become confused, there is a big warning at the top of that file > warning you that it is managed by authselect, and that manual changes > will be overwritten. I don't know what you're talking about here. Am I missing something? Is this a F33 Change? Exact content of my /etc/nsswitch: # # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files in /etc # db Use the pre-processed /var/db files # compat Use /etc files plus *_compat pseudo-databases # hesiod Use Hesiod (DNS) for user lookups # sss Use sssd (System Security Services Daemon) # [NOTFOUND=return] Stop searching if not found so far # # 'sssd' performs its own 'files'-based caching, so it should # generally come before 'files'. # To use 'db', install the nss_db package, and put the 'db' in front # of 'files' for entries you want to be looked up first in the # databases, like this: # # passwd:db files # shadow:db files # group: db files passwd: sss files shadow: sss files group: sss files hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname bootparams: files ethers: files netmasks: files networks: files protocols: files rpc:files services: sss files netgroup: sss publickey: files automount: sss files aliases:files -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Release criteria proposal: first boot experience
On Tuesday, September 1, 2020 1:22:26 PM MST Michael Catanzaro wrote: > Hi, > > We currently have a bug where the Online Accounts page in initial setup > is nonfunctional. [1] This doesn't violate any current release > criterion, but surely we don't want to release with a broken initial > setup experience. So let's add a new requirement for that. How about > something like: > > "If an initial setup utility is run or intended to be run after the > first boot of the installed system, then it must start successfully and > each page or panel of the initial setup utility should withstand a > basic functionality test." > > OK that's pretty basic, but it gets the point across. I think this can > be a final requirement, not necessarily important enough to be a beta > requirement. Bikeshed away! > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476 I would like to report a bug with the first boot experience: Upon installing a new GNOME system, I'm accosted with a dialog asking me questions about the system I just finished configuring in Anaconda. Is there something in Anaconda I'm missing to disable this behavior, or do I have to write my own kickstart to fix that? -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fixing an uninstallable package
On 01. 09. 20 23:32, Tony Asleson wrote: On 9/1/20 12:29 PM, Tony Asleson wrote: On 9/1/20 12:10 PM, Miro Hrončok wrote: On 01. 09. 20 15:39, Tony Asleson wrote: A few weeks ago the package pywbem was updated to latest upstream release and exists in rawhide repo. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f878bb809 The package fails to install because of newly added dependencies that were introduced upstream. So previous working package was python3-pywbem-0.14.6-4.fc34.noarch failing to install and wouldn't work if it did python3-pywbem-1.0.1-1.fc34.noarch.rpm From looking at docs it would appear that utilizing epoch is the answer and I have that ready to go, ref. https://src.fedoraproject.org/rpms/pywbem/pull-request/5 . My question is would it be acceptable to remove the broken package from koji and bump and rebuild the previous working version as no one was able to install it anyway? We cannot remove the package from Koji, but yes -- when you do a new build with higher release than the latest installbale package, you don't need to bump (introduce) the epoch. OK, I'll strip the epoch and give it a try. I tried this and it's not looking good at the moment. The automated tests are reporting some failures which I believe indicate versioning is a problem. https://bodhi.fedoraproject.org/updates/FEDORA-2020-afae078032 Maybe I'm not understanding your response correctly, but I'm still thinking I need to introduce epoch into the spec file to get dnf and other tools to figure the versioning out. I believe you don't. The tests do a static analysis and they are correct, but if it was indeed impossible to ever install python3-pywbem-1.0.1-1.fc33, than you don't have to worry about it, because in reality, it won't ever be a problem. Just make sure to do it before Fedora 33 Final freeze, so the uninstallable but higher version doesn't end up in the "fedora" repo forever. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Fixing an uninstallable package
On 9/1/20 12:29 PM, Tony Asleson wrote: > On 9/1/20 12:10 PM, Miro Hrončok wrote: >> On 01. 09. 20 15:39, Tony Asleson wrote: >>> A few weeks ago the package pywbem was updated to latest upstream >>> release and exists in rawhide repo. >>> >>> https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f878bb809 >>> >>> The package fails to install because of newly added dependencies that >>> were introduced upstream. >>> >>> So previous working package was >>> >>> python3-pywbem-0.14.6-4.fc34.noarch >>> >>> >>> failing to install and wouldn't work if it did >>> >>> python3-pywbem-1.0.1-1.fc34.noarch.rpm >>> >>> >>> From looking at docs it would appear that utilizing epoch is the answer >>> and I have that ready to go, ref. >>> >>> https://src.fedoraproject.org/rpms/pywbem/pull-request/5 . >>> >>> My question is would it be acceptable to remove the broken package from >>> koji and bump and rebuild the previous working version as no one was >>> able to install it anyway? >> >> We cannot remove the package from Koji, but yes -- when you do a new >> build with higher release than the latest installbale package, you don't >> need to bump (introduce) the epoch. > > OK, I'll strip the epoch and give it a try. I tried this and it's not looking good at the moment. The automated tests are reporting some failures which I believe indicate versioning is a problem. https://bodhi.fedoraproject.org/updates/FEDORA-2020-afae078032 Maybe I'm not understanding your response correctly, but I'm still thinking I need to introduce epoch into the spec file to get dnf and other tools to figure the versioning out. -Tony ___ 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
FedoraRespin-32-updates-20200901.0 compose check report
No missing expected images. Failed openQA tests: 3/37 (x86_64) ID: 652576 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/652576 ID: 652595 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/652595 ID: 652604 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/652604 Soft failed openQA tests: 2/37 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 652585 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/652585 ID: 652587 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/652587 Passed openQA tests: 32/37 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Release criteria proposal: first boot experience
Hi, We currently have a bug where the Online Accounts page in initial setup is nonfunctional. [1] This doesn't violate any current release criterion, but surely we don't want to release with a broken initial setup experience. So let's add a new requirement for that. How about something like: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test." OK that's pretty basic, but it gets the point across. I think this can be a final requirement, not necessarily important enough to be a beta requirement. Bikeshed away! [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476 ___ 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
Dne 31. 08. 20 v 23:35 Adam Williamson napsal(a): > On Mon, 2020-08-31 at 15:53 -0400, Ben Cotton wrote: >> >> Accepted blockers >> - >> 1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST >> abrt-server errors when processing zstd compressed core dumps produced >> by systemd-246~rc1-1.fc33 >> >> FEDORA-2020-59e144acee contains a potential fix, but introduces a new >> blocker (BZ 1873029). It may be moot until the retrace server is >> brought back online. > > I'll just note the same team is responsible for this whole complex - > the retrace and FAF servers, and the abrt/libreport tool cluster - so > ultimately the ask here of that team is: get the whole kaboodle working > so we can actually report crashes in F33. The status of the HW: * it is racked in RDU2 * there has been issue in networking * with Smoodge (and bunch of others) help it get some temporary network setup, so we can ssh-access it now. * I hope that this week it will be configured and I hope that by next week it will be available under the original address. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ 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: Non-responsive maintainer: domcleal
On 01. 09. 20 19:40, Robbie Harwood wrote: You may remove me from these packages or orphan them as you see fit. I don't plan on making any more contributions. Done. domcleal is maintainer of rpms/augeas domcleal is no longer maintaining rpms/augeas domcleal is no longer watching rpms/augeas domcleal is watching rpms/direnv domcleal is no longer watching rpms/direnv domcleal is main admin of rpms/freight domcleal is no longer the main admin of rpms/freight domcleal is no longer watching rpms/freight domcleal is maintainer of rpms/puppet domcleal is no longer maintaining rpms/puppet domcleal is no longer watching rpms/puppet domcleal is maintainer of rpms/ruby-augeas domcleal is no longer maintaining rpms/ruby-augeas domcleal is no longer watching rpms/ruby-augeas domcleal is main admin of rpms/rubygem-Ascii85 domcleal is no longer the main admin of rpms/rubygem-Ascii85 domcleal is no longer watching rpms/rubygem-Ascii85 domcleal is maintainer of rpms/rubygem-ffi domcleal is no longer maintaining rpms/rubygem-ffi domcleal is no longer watching rpms/rubygem-ffi domcleal is main admin of rpms/rubygem-jgrep domcleal is no longer the main admin of rpms/rubygem-jgrep domcleal is no longer watching rpms/rubygem-jgrep domcleal is maintainer of rpms/rubygem-ldap_fluff domcleal is no longer maintaining rpms/rubygem-ldap_fluff domcleal is no longer watching rpms/rubygem-ldap_fluff domcleal is main admin of rpms/rubygem-paint domcleal is no longer the main admin of rpms/rubygem-paint domcleal is no longer watching rpms/rubygem-paint domcleal is maintainer of rpms/rubygem-pg domcleal is no longer maintaining rpms/rubygem-pg domcleal is no longer watching rpms/rubygem-pg domcleal has a bugzilla override on rpms/rubygem-pg domcleal has no longer a bugzilla overrides on rpms/rubygem-pg domcleal is main admin of rpms/rubygem-rkerberos domcleal is no longer the main admin of rpms/rubygem-rkerberos domcleal is no longer watching rpms/rubygem-rkerberos domcleal is maintainer of rpms/rubygem-ruby-libvirt domcleal is no longer maintaining rpms/rubygem-ruby-libvirt domcleal is no longer watching rpms/rubygem-ruby-libvirt domcleal is main admin of rpms/rubygem-ruby-rc4 domcleal is no longer the main admin of rpms/rubygem-ruby-rc4 domcleal is no longer watching rpms/rubygem-ruby-rc4 domcleal is maintainer of rpms/rubygem-scoped_search domcleal is no longer maintaining rpms/rubygem-scoped_search domcleal is no longer watching rpms/rubygem-scoped_search domcleal is maintainer of rpms/rubygem-sinatra domcleal is no longer maintaining rpms/rubygem-sinatra domcleal is no longer watching rpms/rubygem-sinatra domcleal has a bugzilla override on rpms/rubygem-sinatra domcleal has no longer a bugzilla overrides on rpms/rubygem-sinatra domcleal is main admin of rpms/rubygem-unicode-display_width domcleal is no longer the main admin of rpms/rubygem-unicode-display_width domcleal is no longer watching rpms/rubygem-unicode-display_width domcleal is main admin of rpms/rubygem-wirb domcleal is no longer the main admin of rpms/rubygem-wirb domcleal is no longer watching rpms/rubygem-wirb -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
On 01/09/2020 18:29, kevin wrote: Just to make sure folks know, the retrace server being down is not this teams fault, it's ours (infrastructure). We planned to just have it down for a week or less when moving it to RDU, but it turned out that datacenter move was not at all what we hoped for and it's been down much longer than intended. That said, we have a machine up now there and it's just needing configuration/setup to get the service back up and running. :) So, hopefully soon it will again be online. Hasn't it effectively been down for like a year anyway? What was the last release it could actually retrace? 30? or was it 31? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 System-Wide Change proposal: systemd-resolved
Den mån 31 aug. 2020 kl 22:40 skrev Michael Catanzaro : > On Mon, Aug 31, 2020 at 10:19 pm, Andreas Tunek > wrote: > > I can't get that command to do anything useful in either F32 or F33. > > You should see something like: > > $ resolvectl query example.com > example.com: 2606:2800:220:1:248:1893:25c8:1946 -- link: tun0 > 93.184.216.34 -- link: tun0 > > -- Information acquired via protocol DNS in 86.4ms. > -- Data is authenticated: no > > And that should be working out-of-the-box in F33. > > > However, if I write "http://nas-name.local in F32 in either Firefox > > or Gnome Web I can connect to my NAS, but if I write the same in F33 > > in the same programs I get an error. > > Ah, I bet this your NAS is mDNS, which is broken right now: > https://bugzilla.redhat.com/show_bug.cgi?id=1867830 > > Thanks, I added the little info I have to the bug report. /Andreas > Until the root cause is diagnosed, here is a workaround you can try. As > root, open up /etc/authselect/user-nsswitch.conf and look at the hosts > line. In a freshly-installed F33 system, it should look like this: > > hosts: resolve [!UNAVAIL=return] myhostname files mdns4_minimal > [NOTFOUND=return] dns > > This says: "if resolved is running, and it doesn't return a hostname, > then STOP and don't try anything else." Everything else is listed only > for the case where resolved is not running. But since resolved is > currently not resolving mDNS as expected, let's change it to check with > avahi first, then check with resolved second, like this: > > hosts: mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] > myhostname files dns > > Then, as root, run: > > # authselect apply-changes > > and then restart your browser. That's not the configuration we want to > use in F33, but hopefully it will "fix" your problem. Please let me > know if it works! > > 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 > ___ 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: Non-responsive maintainer: domcleal
"Dominic Cleal" writes: > Hi Robbie, > > On Tue, 1 Sep 2020, at 4:54 PM, Robbie Harwood wrote: >> Hi, in accordance with [1] this is a non-responsive maintainer check for >> Dominic Cleal. >> [..] >> So, does anyone know how to contact Dominic? > > You may remove me from these packages or orphan them as you see fit. I > don't plan on making any more contributions. Appreciate the prompt response, and thanks for your past work! Thanks, --Robbie signature.asc Description: PGP 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
Re: FYI Fedora 34 OCaml 4.11.1 rebuild
On Tue, Sep 01, 2020 at 11:10:56AM -0600, Jerry James wrote: > On Tue, Sep 1, 2020 at 10:28 AM Richard W.M. Jones wrote: > > We did a Fedora 34 OCaml 4.11.0 rebuild a couple of weeks back, > > something like 170+ packages. Well, a compiler bug was found and > > upstream released OCaml 4.11.1. Details here: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1870368#c26 > > > > So I'm going to do a 4.11.1 build (into a side tag first). I'm not > > expecting there to be any problems since we fixed all the build bugs > > mostly related to ocaml-dune and LTO so recently. > > This release is also supposed to contain a workaround for the problem > I had building prooftree: > > https://github.com/ocaml/ocaml/issues/9859 > > Is prooftree on your list of OCaml packages? I may have neglected to > inform you of its existence. Nope, but it is now :-) For reference the list is here: http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=blob;f=Goalfile > I opened pull requests on ocaml-seq and ocaml-react a couple of hours > ago. If you have time, it would be great if you could look at those. > They represent an opportunity to get rid of patches, if nothing else. Oh right, I saw those but assumed it was somebody else's problem. I'll merge those in a minute. > I tried to update coq to version 8.12.0 yesterday, but the build > failed with a segfault on s390x. The OCaml 4.11.1 release notes talk > about possible segfaults with 4.11.0, so I hope 4.11.1 resolves the > issue. I'll need to push a few small updates to git for the packages > that sit on top of coq. I'll do that in the next hour or so. > > > At some point we will probably need to port all of this to Fedora 33 > > which is stuck on a 4.11.0 pre-release, but I'll worry about that > > later. > > Some F33 OCaml packages have broken deps right now, so a build of some > kind will be necessary. > > Thanks for always doing the yeoman's work with the OCaml packages. > You probably don't get a lot of appreciation for that, so I just > wanted you to know that I appreciate it. No probs! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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
On Tue, 2020-09-01 at 10:29 -0700, kevin wrote: > On Mon, Aug 31, 2020 at 02:35:29PM -0700, Adam Williamson wrote: > > On Mon, 2020-08-31 at 15:53 -0400, Ben Cotton wrote: > > > > > > Accepted blockers > > > - > > > 1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST > > > abrt-server errors when processing zstd compressed core dumps produced > > > by systemd-246~rc1-1.fc33 > > > > > > FEDORA-2020-59e144acee contains a potential fix, but introduces a new > > > blocker (BZ 1873029). It may be moot until the retrace server is > > > brought back online. > > > > I'll just note the same team is responsible for this whole complex - > > the retrace and FAF servers, and the abrt/libreport tool cluster - so > > ultimately the ask here of that team is: get the whole kaboodle working > > so we can actually report crashes in F33. > > Just to make sure folks know, the retrace server being down is not this > teams fault, it's ours (infrastructure). We planned to just have it down > for a week or less when moving it to RDU, but it turned out that > datacenter move was not at all what we hoped for and it's been down much > longer than intended. > > That said, we have a machine up now there and it's just needing > configuration/setup to get the service back up and running. :) > So, hopefully soon it will again be online. Sorry about that, thanks for the correction. I think for Beta at least it would be acceptable if we can submit reports via local backtrace generation - i.e. if the tools correctly handled the servers being down and fell back. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: Fixing an uninstallable package
On 9/1/20 12:10 PM, Miro Hrončok wrote: > On 01. 09. 20 15:39, Tony Asleson wrote: >> A few weeks ago the package pywbem was updated to latest upstream >> release and exists in rawhide repo. >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f878bb809 >> >> The package fails to install because of newly added dependencies that >> were introduced upstream. >> >> So previous working package was >> >> python3-pywbem-0.14.6-4.fc34.noarch >> >> >> failing to install and wouldn't work if it did >> >> python3-pywbem-1.0.1-1.fc34.noarch.rpm >> >> >> From looking at docs it would appear that utilizing epoch is the answer >> and I have that ready to go, ref. >> >> https://src.fedoraproject.org/rpms/pywbem/pull-request/5 . >> >> My question is would it be acceptable to remove the broken package from >> koji and bump and rebuild the previous working version as no one was >> able to install it anyway? > > We cannot remove the package from Koji, but yes -- when you do a new > build with higher release than the latest installbale package, you don't > need to bump (introduce) the epoch. OK, I'll strip the epoch and give it a try. Thanks, Tony ___ 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
On Mon, Aug 31, 2020 at 02:35:29PM -0700, Adam Williamson wrote: > On Mon, 2020-08-31 at 15:53 -0400, Ben Cotton wrote: > > > > Accepted blockers > > - > > 1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST > > abrt-server errors when processing zstd compressed core dumps produced > > by systemd-246~rc1-1.fc33 > > > > FEDORA-2020-59e144acee contains a potential fix, but introduces a new > > blocker (BZ 1873029). It may be moot until the retrace server is > > brought back online. > > I'll just note the same team is responsible for this whole complex - > the retrace and FAF servers, and the abrt/libreport tool cluster - so > ultimately the ask here of that team is: get the whole kaboodle working > so we can actually report crashes in F33. Just to make sure folks know, the retrace server being down is not this teams fault, it's ours (infrastructure). We planned to just have it down for a week or less when moving it to RDU, but it turned out that datacenter move was not at all what we hoped for and it's been down much longer than intended. That said, we have a machine up now there and it's just needing configuration/setup to get the service back up and running. :) So, hopefully soon it will again be online. kevin signature.asc Description: PGP 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
Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)
On Tue, Sep 1, 2020 at 3:22 AM Frantisek Zatloukal wrote: > > > > On Thu, Aug 27, 2020 at 5:16 PM Ben Cotton wrote: >> >> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS >> >> == Summary == >> Improve compression ratio of SquashFS filesystem on the installation media. >> >> == Owner == >> * Name: [[User:bkhomuts|Bohdan Khomutskyi]] >> * Email: bkhom...@redhat.com >> > > I think we should aim for faster installations and lower cpu usage (zstd), > not smaller ISO size (xz). > > Saving 142 MBs isn't going to make a huge difference in download times > (disclaimer: I don't know how is the internet connection speed in other > areas, I have not that fast connection of 200mbps down (slowest possible in > my area), so 142 MB saving would make roughly 6 seconds difference myself). > > On the other hand, saving minutes in the installation process (as seen with > zstd if I am reading the numbers correctly) is not only going to help users > with installation times, but also us, Fedora QA, with faster testing, both > manual and automated (OpenQA). I haven't benchmarked a physical USB stick, they vary so much in read speeds these days. But it's possible to likely there's minimal gain in performance from USB sticks, but for sure reduced CPU utilization because zstd is just way more efficient than lzma when decompressing. For VM's including openQA automated tests, I expect it will make a difference. Zstd will be faster. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fixing an uninstallable package
On 01. 09. 20 15:39, Tony Asleson wrote: A few weeks ago the package pywbem was updated to latest upstream release and exists in rawhide repo. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f878bb809 The package fails to install because of newly added dependencies that were introduced upstream. So previous working package was python3-pywbem-0.14.6-4.fc34.noarch failing to install and wouldn't work if it did python3-pywbem-1.0.1-1.fc34.noarch.rpm From looking at docs it would appear that utilizing epoch is the answer and I have that ready to go, ref. https://src.fedoraproject.org/rpms/pywbem/pull-request/5 . My question is would it be acceptable to remove the broken package from koji and bump and rebuild the previous working version as no one was able to install it anyway? We cannot remove the package from Koji, but yes -- when you do a new build with higher release than the latest installbale package, you don't need to bump (introduce) the epoch. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: FYI Fedora 34 OCaml 4.11.1 rebuild
On Tue, Sep 1, 2020 at 10:28 AM Richard W.M. Jones wrote: > We did a Fedora 34 OCaml 4.11.0 rebuild a couple of weeks back, > something like 170+ packages. Well, a compiler bug was found and > upstream released OCaml 4.11.1. Details here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1870368#c26 > > So I'm going to do a 4.11.1 build (into a side tag first). I'm not > expecting there to be any problems since we fixed all the build bugs > mostly related to ocaml-dune and LTO so recently. This release is also supposed to contain a workaround for the problem I had building prooftree: https://github.com/ocaml/ocaml/issues/9859 Is prooftree on your list of OCaml packages? I may have neglected to inform you of its existence. I opened pull requests on ocaml-seq and ocaml-react a couple of hours ago. If you have time, it would be great if you could look at those. They represent an opportunity to get rid of patches, if nothing else. I tried to update coq to version 8.12.0 yesterday, but the build failed with a segfault on s390x. The OCaml 4.11.1 release notes talk about possible segfaults with 4.11.0, so I hope 4.11.1 resolves the issue. I'll need to push a few small updates to git for the packages that sit on top of coq. I'll do that in the next hour or so. > At some point we will probably need to port all of this to Fedora 33 > which is stuck on a 4.11.0 pre-release, but I'll worry about that > later. Some F33 OCaml packages have broken deps right now, so a build of some kind will be necessary. Thanks for always doing the yeoman's work with the OCaml packages. You probably don't get a lot of appreciation for that, so I just wanted you to know that I appreciate it. Regards, -- Jerry James http://www.jamezone.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: FYI Fedora 34 OCaml 4.11.1 rebuild
On Tue, 2020-09-01 at 17:27 +0100, Richard W.M. Jones wrote: > We did a Fedora 34 OCaml 4.11.0 rebuild a couple of weeks back, > something like 170+ packages. Well, a compiler bug was found and > upstream released OCaml 4.11.1. Details here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1870368#c26 > > So I'm going to do a 4.11.1 build (into a side tag first). I'm not > expecting there to be any problems since we fixed all the build bugs > mostly related to ocaml-dune and LTO so recently. ACK. If anything new pops up in the LTO space, please reach out. JEff > ___ 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
FYI Fedora 34 OCaml 4.11.1 rebuild
We did a Fedora 34 OCaml 4.11.0 rebuild a couple of weeks back, something like 170+ packages. Well, a compiler bug was found and upstream released OCaml 4.11.1. Details here: https://bugzilla.redhat.com/show_bug.cgi?id=1870368#c26 So I'm going to do a 4.11.1 build (into a side tag first). I'm not expecting there to be any problems since we fixed all the build bugs mostly related to ocaml-dune and LTO so recently. At some point we will probably need to port all of this to Fedora 33 which is stuck on a 4.11.0 pre-release, but I'll worry about that later. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ 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
Non-responsive maintainer: domcleal
Hi, in accordance with [1] this is a non-responsive maintainer check for Dominic Cleal. Non-responsive bug: https://bugzilla.redhat.com/show_bug.cgi?id=1874569 Unactioned bugs (earliest is January 2018): https://bugzilla.redhat.com/show_bug.cgi?id=1538845 https://bugzilla.redhat.com/show_bug.cgi?id=1523910 https://bugzilla.redhat.com/show_bug.cgi?id=1508684 https://bugzilla.redhat.com/show_bug.cgi?id=1463460 https://bugzilla.redhat.com/show_bug.cgi?id=1766913 https://bugzilla.redhat.com/show_bug.cgi?id=1868381 So, does anyone know how to contact Dominic? Thanks, --Robbie 1: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ signature.asc Description: PGP 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
Fedora-IoT-33-20200901.0 compose check report
No missing expected images. Soft failed openQA tests: 3/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-33-20200829.0): ID: 652533 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/652533 ID: 652534 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/652534 ID: 652538 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/652538 Passed openQA tests: 13/16 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)
On Tue, Sep 1, 2020 at 5:23 AM Frantisek Zatloukal wrote: > > Saving 142 MBs isn't going to make a huge difference in download times > (disclaimer: I don't know how is the internet connection speed in other > areas, I have not that fast connection of 200mbps down (slowest possible in > my area), so 142 MB saving would make roughly 6 seconds difference myself). > Just for context, I also have 200Mbps down and that's not quite the fastest possible in my area but it's basically the fastest residential connection that people actually get. Most people that I know in this part of the US have 50-100Mbps and they don't always get it. The other consideration, apart from raw performance, is bandwidth caps. I won't pretend to know where places have caps, but I have heard a lot of Australian friends complain about them over the years. My understanding, at least in the US, is that providers have largely dropped the caps in These Uncertain Times[tm], but that can be a factor for people too. > On the other hand, saving minutes in the installation process (as seen with > zstd if I am reading the numbers correctly) is not only going to help users > with installation times, but also us, Fedora QA, with faster testing, both > manual and automated (OpenQA). > This is also true. Certainly it would help *us* to have faster installation times. I'm less convinced that it's meaningful to the majority of our users. Totally guessing, but I'd suspect that most (as in 90%) Fedora users have 1-5 or mayyybe 5-10 machines and they're not frequently re-installing them. I'd love to see the distribution of machines per user, but I don't think we'll ever know that in a reliable sense. But I do think that optimizing the install time is a meaningful benefit to only a very small portion of the audience. It's an important portion, though, so we have to decide if it outweighs the benefit to those who would be better served with a smaller download. I don't think a 25 second increase in install time will be that noticeable for most people (though, yes, those seconds add up). What I think we're missing is beyond the scope of this proposal: a context for what we're trying to achieve. What targets do we have for build time, image size, and installation time? With that, we can then make decisions about how to balance tradeoffs within that context. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora-IoT 33 RC 20200901.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 33 RC 20200901.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/33iot You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200901.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200901.0_General Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Tue, Sep 1, 2020 at 8:17 am, Nico Kadel-Garcia wrote: Hiding it inside yet another systemd structure without following the existing standards is, sadly, typical of systemd. It also puts at risk restricted environments where providing no DNS is deliberately used to restrict outbound network use, such as virtual machines or chroot cages without an enabled /etc/resolv.conf. That includes the "mock" build environment where "pip install" is kept network disabled by the lack of DNS. So open up /etc/systemd/resolved.conf and set FallbackDNS= (set it to nothing). That will override fallback to Cloudflare or Google. Then you're done. Realistically, this fallback is unlikely to ever be used anyway, so it doesn't matter very much. And if you're operating a restricted environment and you don't know how to configure DNS, you likely have bigger problems than systemd It will also completely screw up VPN setups where out-of-band DNS servers break internal versus external service access management. No it won't. systemd is not going to use a fallback DNS server if your VPN provides its own DNS. It's not stupid. This is very easily verified simply by typing 'resolvectl' and seeing what DNS servers it has configured for a particular tun interface. 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
Fedora-33-20200901.n.0 compose check report
No missing expected images. Failed openQA tests: 10/181 (x86_64) New failures (same test not failed in Fedora-33-20200831.n.0): ID: 652454 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/652454 ID: 652468 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/652468 Old failures (same test failed in Fedora-33-20200831.n.0): ID: 652423 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/652423 ID: 652429 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/652429 ID: 652461 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/652461 ID: 652471 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/652471 ID: 652472 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/652472 ID: 652502 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/652502 ID: 652529 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/652529 ID: 652530 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/652530 Soft failed openQA tests: 86/181 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-33-20200831.n.0): ID: 652412 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/652412 Old soft failures (same test soft failed in Fedora-33-20200831.n.0): ID: 652352 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/652352 ID: 652353 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/652353 ID: 652355 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/652355 ID: 652356 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/652356 ID: 652357 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/652357 ID: 652358 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/652358 ID: 652359 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/652359 ID: 652360 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/652360 ID: 652363 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/652363 ID: 652364 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/652364 ID: 652365 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/652365 ID: 652366 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/652366 ID: 652381 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/652381 ID: 652387 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/652387 ID: 652392 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/652392 ID: 652393 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/652393 ID: 652410 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/652410 ID: 652433 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/652433 ID: 652434 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/652434 ID: 652444 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/652444 ID: 652451 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/652451 ID: 652452 Test: x86_64 universal install_blivet_with_swap URL: https://openqa.fedoraproject.org/tests/652452 ID: 652453 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/652453 ID: 652458 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/652458 ID: 652459 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/652459 ID: 652460 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/652460 ID: 652465 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/652465 ID: 652466 Test: x86_64 universal
Re: fedora-secondary boot image timeout
On Tue, 1 Sep 2020 08:25:03 -0500 Greg Hellings wrote: > I'm sorry, I don't know where the boot media information is kept, otherwise > I would raise my question there, instead. I'm trying to automate the > creation of ppc64le systems. x86_64 ISOs have a 30 second timeout on the > boot menu. ppc64le machines have a 5 second timeout. With the vagaries of > system startup time, this makes a VERY narrow window for my automation to > jump on and modify the boot parameters with kickstart info. > > Where can I suggest this change, or discuss it with the people who own it? if you mean the timeout in the boot menu in the installer ISO, then they are defined in the bootloader config files carried by lorax, see https://github.com/weldr/lorax/tree/master/share/templates.d/99-generic/config_files Dan ___ 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 System-Wide Change proposal: systemd-resolved
On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr wrote: Michael, The file is /etc/nsswitch.conf. You're wasting everyone's time with these low-effort spam posts. Lest anyone become confused, there is a big warning at the top of that file warning you that it is managed by authselect, and that manual changes will be overwritten. Anyway, it seems this problem was not related to mDNS at all, so doesn't matter. ___ 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
Fixing an uninstallable package
A few weeks ago the package pywbem was updated to latest upstream release and exists in rawhide repo. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f878bb809 The package fails to install because of newly added dependencies that were introduced upstream. So previous working package was python3-pywbem-0.14.6-4.fc34.noarch failing to install and wouldn't work if it did python3-pywbem-1.0.1-1.fc34.noarch.rpm From looking at docs it would appear that utilizing epoch is the answer and I have that ready to go, ref. https://src.fedoraproject.org/rpms/pywbem/pull-request/5 . My question is would it be acceptable to remove the broken package from koji and bump and rebuild the previous working version as no one was able to install it anyway? At the moment we aren't sure how we want to handle the change & newly added dependencies to the latest upstream version. This package may ultimately get orphaned. Thanks, Tony ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 compose report: 20200901.n.0 changes
OLD: Fedora-33-20200831.n.0 NEW: Fedora-33-20200901.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 1 Dropped packages:0 Upgraded packages: 5 Downgraded packages: 0 Size of added packages: 32.25 MiB Size of dropped packages:0 B Size of upgraded packages: 180.45 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -48.90 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-33-20200831.n.0-sda.raw.xz = ADDED PACKAGES = Package: gnome-tour-3.37.91-2.fc33 Summary: GNOME Tour and Greeter RPMs:gnome-tour Size:32.25 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: blender-1:2.83.5-4.fc33 Old package: blender-1:2.82a-5.fc33 Summary: 3D modeling, animation, rendering and post-production RPMs: blender blender-fonts blender-rpm-macros Size: 122.92 MiB Size change: -49.08 MiB Changelog: * Wed Jun 03 2020 Luya Tshimbalanga - 1:2.83.0-1 - Update to 2.83.0 (#1843623) - Clean up spec file * Sun Jun 14 2020 Luya Tshimbalanga - 1:2.83.0-1.1 - Temporarily exclude ARM architecture (#1843100) * Sat Jun 20 2020 Luya Tshimbalanga - 1:2.83.0-2 - Remove undocumented and undefined function on Python 3.9 - Use documented python function defined on Python 3.9 (#1843100) * Sun Jun 21 2020 Luya Tshimbalanga - 1:2.83.0-3 - Fix installtion path for fonts directory (#1849429) - More conversion to pkgconf format * Sun Jun 21 2020 Luya Tshimbalanga - 1:2.83.0-4 - Apply upstream patch to build on Python 3.9 (#1843100) * Thu Jun 25 2020 Luya Tshimbalanga - 1:2.83.1-1 - Update to 2.83.1 (#1843623) * Thu Jul 09 2020 Luya Tshimbalanga - 1:2.83.2-1 - Update to 2.83.2 (#1855165) * Thu Jul 09 2020 Luya Tshimbalanga - 1:2.83.2-2 - Add openshadinglanguage dependency - Reenable upstream patch to build on Python 3.9 for Fedora 33+ (#1843100) * Wed Jul 22 2020 Luya Tshimbalanga - 1:2.83.3-1 - Update to 2.83.3 (#1855165) - Enable embree and osl for cycles rendering * Mon Jul 27 2020 Fedora Release Engineering - 1:2.83.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Aug 01 2020 Fedora Release Engineering - 1:2.83.3-3 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Aug 01 2020 Luya Tshimbalanga - 1:2.83.3-4 - Use cmake macros for build and install * Wed Aug 05 2020 Luya Tshimbalanga - 1:2.83.4-1 - Update to 2.83.4 (#1855165) * Wed Aug 19 2020 Luya Tshimbalanga - 1:2.83.5-1 - Update to 2.83.5 (#1855165) * Mon Aug 24 2020 Simone Caronni - 1:2.83.5-2 - Be consistent with build options format and distribution conditionals. - rpmlint fixes. - Fix build dependencies. - Fix Python 3.9 patch. - Disable OpenShadingLanguage, 1.11 is not supported. - Disable Embree, 3.11 is not supported. * Tue Aug 25 2020 Charalampos Stratakis - 1:2.83.5-3 - Use c++14 for properly building with the latest version of openvdb * Tue Aug 25 2020 Luya Tshimbalanga - 1:2.83.5-4 - Temporarily exclude s390x second architecutre Package: glib2-2.65.2-3.fc33 Old package: glib2-2.65.2-2.fc33 Summary: A library of handy utility functions RPMs: glib2 glib2-devel glib2-doc glib2-fam glib2-static glib2-tests Size: 38.74 MiB Size change: -885 B Changelog: * Tue Aug 25 2020 Adam Williamson - 2.65.2-3 - Backport fix for GGO #2189 (error accessing some filesystems) Package: gnome-initial-setup-3.37.91.1-2.fc33 Old package: gnome-initial-setup-3.37.91.1-1.fc33 Summary: Bootstrapping your OS RPMs: gnome-initial-setup Size: 5.54 MiB Size change: 1.16 KiB Changelog: * Thu Aug 27 2020 Kalev Lember - 3.37.91.1-2 - Require new gnome-tour package (#1873206) Package: gnome-shell-3.37.91-2.fc33 Old package: gnome-shell-3.37.91-1.fc33 Summary: Window management and application launching for GNOME RPMs: gnome-shell Size: 7.81 MiB Size change: 958 B Changelog: * Wed Aug 26 2020 Kalev Lember - 3.37.91-2 - Add PolicyKit-authentication-agent virtual provides Package: jack-audio-connection-kit-1.9.14-5.fc33 Old package: jack-audio-connection-kit-1.9.14-4.fc33 Summary: The Jack Audio Connection Kit RPMs: jack-audio-connection-kit jack-audio-connection-kit-dbus jack-audio-connection-kit-devel jack-audio-connection-kit-example-clients Size: 5.46 MiB Size change: 191.38 KiB Changelog: * Tue Aug 25 2020 Guido Aulisi - 1.9.14-5 - Disable LTO (#1872065, #1869059) = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US
fedora-secondary boot image timeout
I'm sorry, I don't know where the boot media information is kept, otherwise I would raise my question there, instead. I'm trying to automate the creation of ppc64le systems. x86_64 ISOs have a 30 second timeout on the boot menu. ppc64le machines have a 5 second timeout. With the vagaries of system startup time, this makes a VERY narrow window for my automation to jump on and modify the boot parameters with kickstart info. Where can I suggest this change, or discuss it with the people who own it? --Greg ___ 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
Schedule for Wednesday's FESCo Meeting (2020-09-02)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-09-02 14:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #2460 Non-responsive maintainers: ... https://pagure.io/fesco/issue/2460 DECISION: affix amitshah ggillies ignotusp luismartingil mbartos mhabrnal mildew nguzman robled sspreitz svahl are deemed non-responsive and their packages have been orphaned (+3, 0, 0). (A few other names were initially listed in the ticket, but have responded and their status has been cleared.) = Followups = #2454 Proposal: Require compiler / annobin updates to use rawhide gating https://pagure.io/fesco/issue/2454 #2416 Update 3rd party repo policy https://pagure.io/fesco/issue/2416 = New business = (none) = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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 System-Wide Change proposal: systemd-resolved
* Roberto Ragusa: > Standard DNS has a hierarchical structure with roots and delegation. > The idea of asking somebody to do DNS resolution for you comes from > the widespread tendency to centralize everything (i.e. inability to > understand how the Internet was originally designed). DNS originally did not have a clear hierarchical structure. You just asked one server you liked, and it would point you towards a server somewhat closer to the data source if it did not have the answer itself. The hierarchy was always there in the background, to ensure eventually successful lookups, but it gained prominence in implementations only once it became apparent that you can only use data from servers that are actually authoritative for the subtree in which the data resides. Otherwise, you end up with rather trivial spoofing attacks. > Insisting on using a DNS server for name resolution is like insisting > on using a proxy for HTTP access. I'm not sure if that's the appropriate analogy. Most of us don't run BGP on their laptops, and DNS is closer to that layer than to HTTP. But it definitely doesn't make sense to create a deep hierarchy of resolvers, somehow mirroring the hierarchy of delegation. > The only sane DNS server we should have is the one on localhost (doing > proper caching according to TTLs). Many networks block outgoing UDP traffic, so you cannot run DNS locally at all. There are also concerns that the DNS infrastructure cannot handle the load unless there is one level of shared caching betweeen the endpoints and the authoritative servers. Those DNS caches certainly suppress some of the problematic client behavior (but they also add their own share of broken queries, of course). Thanks, Florian ___ 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 System-Wide Change proposal: systemd-resolved
* John M. Harris, Jr.: > Sure, those two companies will be thrilled, I'm sure. This is a huge > disservice to our users. Why in the world does systemd try to force DNS > servers when none are configured? If no DNS servers are configured, there > should be no DNS servers in use. Acutally, the historic default is to use localhost (127.0.0.1). This is what an empty or missing /etc/resolv.conf file has always meant. (Okay, there was apparently a time when localhost could also be reached at 0.0.0.0, and that was the default before 127.0.0.1. But that likely predates the Linux networking stack.) Thanks, Florian ___ 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 System-Wide Change proposal: systemd-resolved
On Tue, Sep 1, 2020 at 3:34 AM Roberto Ragusa wrote: > > On 2020-09-01 08:52, John M. Harris Jr wrote: > > On Monday, August 31, 2020 8:32:49 AM MST Vitaly Zaitsev via devel wrote: > >> On 31.08.2020 17:07, John M. Harris Jr wrote: > >> > >>> ship a release with "fallback" to Google and Cloudflare DNS? > >> > >> > >> Big Brother will be happy. :-) > > > > Sure, those two companies will be thrilled, I'm sure. This is a huge > > disservice to our users. Why in the world does systemd try to force DNS > > servers when none are configured? If no DNS servers are configured, there > > should be no DNS servers in use. > > Standard DNS has a hierarchical structure with roots and delegation. > The idea of asking somebody to do DNS resolution for you comes from the > widespread > tendency to centralize everything (i.e. inability to understand how the > Internet was > originally designed). Hiding it inside yet another systemd structure without following the existing standards is, sadly, typical of systemd. It also puts at risk restricted environments where providing no DNS is deliberately used to restrict outbound network use, such as virtual machines or chroot cages without an enabled /etc/resolv.conf. That includes the "mock" build environment where "pip install" is kept network disabled by the lack of DNS. It will also completely screw up VPN setups where out-of-band DNS servers break internal versus external service access management. > Insisting on using a DNS server for name resolution is like insisting on > using a proxy > for HTTP access. It's secretly cooking the fries in bacon grease. It not only offends people such as vegetarians, Muslims, and Jews but it creates an unnecessary health risk for people with the "Alpha-Gal" meat allergy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)
On Fri, Aug 28, 2020 at 12:55 AM Michel Alexandre Salim < mic...@michel-slm.name> wrote: > On Thu, 2020-08-27 at 11:13 -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/OptimizeSquashFS > > > > == Summary == > > Improve compression ratio of SquashFS filesystem on the installation > > media. > > > ... > > > > Based on the results above, I'd suggest selecting the following > > ''optimal configuration'': XZ algorithm, with block size of 1MiB and > > without BCJ filter (plain xz -b 1M, without -Xbcj x86). > > On the right, you can see the impact of the compression algorithms on > > installation time. > > > Why XZ as opposed to, say, ZSTD? > Bohdan's preference seems to be to make the images smaller. I'm in the opposite camp. I'd like to keep the images roughly the same size (or smaller, but just a bit smaller, not as small as possible) and hugely speed up the installation instead. Which means zstd in one of the configurations. Each image is downloaded just once, but installed 1+ times. And with automation and all the CI work which Fedora and Red Hat invests a lot of effort into, it can be a hundred installations from a single image (without being bound to slow USB stick transfer speeds, as in the proposal). Of course, I'm biased. Bohdan, could you build the same image in several configurations (the most likely candidates) and share them with us? (We can host them in our QA fedorapeople space, if needed). That would allow interested parties to test and benchmark the experience themselves. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-versioneer: no version information in github archives?
On Fri, Aug 28, 2020 21:46:19 +0200, Miro Hrončok wrote: > I remember it was but it was extremely hard to use anything but the sdist > when hacking on nb2plots. See: > > https://src.fedoraproject.org/rpms/python-nb2plots/pull-request/2 > > Overall, versioneer behaves very badly when you try to bend it for RPM > packaging. Also, it appears upstream dead and this particular issue is not > getting anywhere: > > https://github.com/warner/python-versioneer/issues/199 > > I'd ask upstream if they could consider using setuptools_scm instead. Thanks very much Miro. I looked at your PR for nb2plots. I'd spent quite a bit of time trying similar git hacks and nothing had worked too. I've let upstream know, and I'll use a similar hack for the time being. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP 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
Fedora-Cloud-31-20200901.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [golang packaging] how to get files from source tarball
Le 2020-08-31 18:08, Zdenek Dohnal a écrit : Hi, I'm trying to package ipp-usb project (https://github.com/OpenPrinting/ipp-usb) which is written in Go. I generated spec file via go2rpm, but several files from source tarball which supposed to be packaged is not packaged e.g. systemd unit file ipp-usb.service or udev rule file 71-ipp-usb.rules. I managed to package those files with following install command e.g.: install -m 0644 -vp %{gobuilddir}/src/github.com/OpenPrinting/ipp-usb/systemd-udev/*.rules %{buildroot}%{_udevrulesdir} but '%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb' is quite ugly - is there a predefined golang macro for such path? Or a best practice? You do not need that at all in most of the spec, the usual workdir is the root of the upstream zip. The complex path you posted is (painfully) symlinked to keep go tools happy in GOPATH mode, anything which is not a "go foo" execution can happily ignore it and just work from the current directory. But if you do need an absolute file path or already changed dir somewhere else '%{gobuilddir}/src/%{goipath}' is likely to be close to what you want. The next gen of Fedora Go tooling will be both simpler and more complex. Simpler because in Go module mode we can drop completely the horrific mandatory root dir renaming to url, adding a src prefix. So in most cases we will just work from the archive root like other languages, without playing brittle directory symlinking games. More complex because upstream Go modules permit submoduling, so submodule roots will be buried deep inside the expanded archive tree. Regards, -- Nicolas Mailhot ___ 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
CPE Weekly: 2020-09-01
Hi everyone, Welcome to September! Below are the most recent Community Platform Engineering project updates, and if you want to know more about our team, see our wiki page here for more information on who our team is: https://docs.fedoraproject.org/en-US/cpe/ Here are some upcoming IRC meetings: ### CPE Product Owner Office Hours #fedora-meeting-1 * Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1 * Next Meeting: 2020-09-03 #centos-meeting * Every second Tuesday @ 1500 UTC on #centos-meeting * Next Meeting: 2020-09-01 GitLab AMA Session * September 10th @ 1330 UTC on #fedora-meeting-1 Below are the project & community updates this week: GitLab There will be an IRC based AMA session with GitLab on Thursday 10th September @ 1330 UTC in place of the CPE PO office hours. We are still talking to GitLab but we are deliberately taking our time to make sure all of the technical blockers can be met and the move will be worth it in the end. There is very little to no updates in the tracker, but I will include it nonetheless https://gitlab.com/gitlab-org/gitlab/-/issues/217350 I will also be sending a separate email on details of the AMA session later this week, such as how to submit questions in advance so there is content ready on the day. ## Fedora Updates ### Staging Environment * Services will begin to be deployed this week * Please be patient as some services will inevitably not work due to networking errors that the team don't know until they deploy * Thank you again for your patience and understanding during these last few months! ### AAA Replacement * Deployment to staging for testing is delayed due to missing firewalls in IAD2 * This has just recently been unblocked so the team will begin some deployment and testing of Noggin this week * Wider community testing will be available, estimated next week * In the meantime. Please feel free to check out the team kanban board for more information on the features the team are working on and have already completed here https://github.com/orgs/fedora-infra/projects/6 ### Fedora Messaging Schemas * List of applications that require messaging schemas can be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit * There is a readme which contains documentation on messaging schemas, a cookie-cutter template to create the schema and a definition of Done for writing a schemas https://github.com/fedora-infra/fedora-messaging-schemas-issues * The board they are working from can be viewed here https://github.com/orgs/fedora-infra/projects/7 ### Packager Workflow Healthcare * The team have been reviewing data on how packages are built in the fedora infrastructure for the last 8 weeks and have gathered enough information to create a report on their findings. * This report is currently in draft format, and is going to be reviewed by the team first, and then sent to the devel and infra lists in the next 2 weeks est. * The teams work is being tracked here https://teams.fedoraproject.org/project/cpe-cicd/kanban ## CentOS Updates ### CentOS * Updated ocp.stg to OCP v4.5.6. * Added a number of users to the jump.ci host. * Adding monitoring/alerting for NFS slowness to the ocp cluster. ### CentOS Stream * Module push tweaks. * Exploring how to enable fedora messaging in Stream * Reviewing documentation on contributor policies before publishing them later this quarter. Here is a reminder of what our team has committed to work on in this quarter of the year: The CPE team are working on the following projects for Quarter 3, which is the months of July, August & September: * Data Centre Move - Final Works * CentOS Stream Phase 3 * Noggin Phase 3 * Packager Workflow Healthcare * Fedora Messaging Schemas Details of the above projects, and of projects currently in progress, done and what projects are in our backlog, can be found on our taiga board per project card: https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null We also have an updated initiative timetable for briefing in new projects to our team & key dates here:https://docs.fedoraproject.org/en-US/cpe/time_tables/ *Note: Initiatives are large pieces of work that require a team of people and weeks/months to complete. Please continue to open tickets in the normal way for bugs, issues, etc. Background: The Community Platform Engineering group, or CPE for short, is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great week! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___
Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)
On Thu, Aug 27, 2020 at 5:16 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/OptimizeSquashFS > > == Summary == > Improve compression ratio of SquashFS filesystem on the installation media. > > == Owner == > * Name: [[User:bkhomuts|Bohdan Khomutskyi]] > * Email: bkhom...@redhat.com > > I think we should aim for faster installations and lower cpu usage (zstd), not smaller ISO size (xz). Saving 142 MBs isn't going to make a huge difference in download times (disclaimer: I don't know how is the internet connection speed in other areas, I have not that fast connection of 200mbps down (slowest possible in my area), so 142 MB saving would make roughly 6 seconds difference myself). On the other hand, saving minutes in the installation process (as seen with zstd if I am reading the numbers correctly) is not only going to help users with installation times, but also us, Fedora QA, with faster testing, both manual and automated (OpenQA). Also, (I am not a marketing expert) I think that having a faster installation process with slightly larger download is going to make the installation process feel faster and help Fedora perception. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20200901.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20200831.0): ID: 652173 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/652173 Passed openQA tests: 6/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fwd: Re: CppunitTest_sw_htmlexport failing due to zlib variation?
On 31/08/2020 23:05, Adenilson Cavalcanti wrote: Joining the discussion, since I worked on the original optimization patches and I'm one of the maintainers of Chromium's zlib. Just seconding what Jeremy mentioned, it is possible to generate a valid DEFLATE stream wrapped with GZIP format that may be different depending on the encoder used (e.g. zlib vs libdeflate vs zopfli). Specifically on the aarch64 specific patches, most probably the patch 0002-Porting-optimized-longest_match.patch would be responsible for the difference observed when compared to a vanilla canonical zlib (i.e. Mark Adler's zlib https://github.com/madler/zlib). That optimization uses a slightly different strategy for finding the matching strings while performing LZ77 compression. Just to be on the safe side, I decided to write a small test case comparing the pixels of the failing libreoffice test to verify if indeed, the decompressed data was a perfect match. The test case can be found here (https://codepen.io/Savago/pen/BaKddem). It displays side-by-side the expected image and the generated image and by clicking in the button, it will print the number of mismatched pixels and also a version of the image with the mismatched highlighted pixels. To prove that the test case is sound, there is another version here (https://codepen.io/Savago/full/qBZXXOv) where I explicitly added some changes in the generated image (i.e. added one eye, smile and a '4' symbol in the chest of the icon using GIMP). I also observed that the generated PNG is actually a few bytes smaller (2066 bytes vs 2102 bytes), which shows slightly better compression. I hope that this should be enough to prove that there are no bugs in the optimization patches used by Fedora. Wow, thanks a lot for going above and beyond to proof my naive assumption was indeed right. :) Unfortunately, there is the common assumption that you could compare binary compressed gzipped data but that fails if a newer version of a compression library implement changes that may improve compression ratio. I looked into the posted fix to libreoffice (https://gerrit.libreoffice.org/c/core/+/101329/3/sw/qa/extras/htmlexport/htmlexport.cxx), that is not ideal since it will just inspect if some PNG was inserted in the document, without actually testing if the pixels match. Yeah, but the reported purpose of that unit test is to verify that an image is embedded, not to verify the correctness of the PNG-generating code. Lets hope that there's other tests in the suite that cover the latter. [...] ___ 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 System-Wide Change proposal: systemd-resolved
On 2020-09-01 08:52, John M. Harris Jr wrote: On Monday, August 31, 2020 8:32:49 AM MST Vitaly Zaitsev via devel wrote: On 31.08.2020 17:07, John M. Harris Jr wrote: ship a release with "fallback" to Google and Cloudflare DNS? Big Brother will be happy. :-) Sure, those two companies will be thrilled, I'm sure. This is a huge disservice to our users. Why in the world does systemd try to force DNS servers when none are configured? If no DNS servers are configured, there should be no DNS servers in use. Standard DNS has a hierarchical structure with roots and delegation. The idea of asking somebody to do DNS resolution for you comes from the widespread tendency to centralize everything (i.e. inability to understand how the Internet was originally designed). Insisting on using a DNS server for name resolution is like insisting on using a proxy for HTTP access. The only sane DNS server we should have is the one on localhost (doing proper caching according to TTLs). I do not know what this new systemd thing will provide (and hardcoded defaults would be a wrong beginning); in my case it has been bind on localhost for years; it lets me have local zones (e.g. plugged in when a VPN goes up) and I can also make it authoritative for external things I want to override (i.e. playing like a super-powered /etc/hosts). Regards. -- Roberto Ragusamail at robertoragusa.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: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."
On Fri, Aug 28, 2020 at 01:47:14PM -, Martin Gansser wrote: > when I want to do a review with: fedora-review -m fedora-rawhide-x86_64 -b > 1873407 > i get this error message: > > warning: line 16: Possible unexpanded macro in: Requires: > vdr(abi)(x86-64) = %{vdr_apiversion} It means the %{vdr_apiversion} macro is not defined > Building target platforms: x86_64 > Building for target x86_64 > setting SOURCE_DATE_EPOCH=1598313600 > Wrote: /builddir/build/SRPMS/vdr-skinelchihd-0.5.0-1.fc34.src.rpm when building the source package. > How can i solve this ? > Requires tags are evaluated when building a source package, although they are not used at this stage in any way. This is a deficiency in a rpmbuild tool. Until (if ever) it is fixed in rpmbuild, you need to work around it in the spec file. First, the macro is not available in a minimal build root used for build source packages. Thus you need to check its definess and use it only if it is defined: Requires: vdr(abi)(%{_isa}) = %{?vdr_apiversion:%{vdr_apiversion}} But that's not all. The Requires tag value must be a valid dependency value after the expansion. In that form it would yield an invalid dependency value "vdr(abi)(x86-64) = ". Thus you need either to supply a dummy value after the equal sign if the macro is not defined, or better just do not generate the dependency at all: %if %{defined vdr_apiversion} Requires: vdr(abi)(%{_isa}) = %{vdr_apiversion} %endif -- Petr signature.asc Description: PGP 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