date:20200901

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

2020-09-01 Thread Neal Gompa

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

2020-09-01 Thread Nico Kadel-Garcia

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

2020-09-01 Thread Ed Greshko

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

[Bug 1874683] New: perl-Locale-Codes-3.65 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1874683

Bug ID: 1874683
   Summary: perl-Locale-Codes-3.65 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Locale-Codes
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.65
Current version/release in rawhide: 3.64-3.fc33
URL: http://search.cpan.org/dist/Locale-Codes/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3033/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fixing an uninstallable package

2020-09-01 Thread Miro Hrončok


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

2020-09-01 Thread Tony Asleson

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

2020-09-01 Thread Michael Catanzaro


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

[Bug 1871053] perl-Module-Load-Conditional-0.74 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1871053



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2020-131bafc061 has been pushed to the Fedora 31 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-131bafc061

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] please review: PR 51258 - remove hardcoded repl changelog filename string

2020-09-01 Thread Mark Reynolds


https://pagure.io/389-ds-base/pull-request/51258

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[Bug 1870878] perl-Module-CoreList-5.20200820 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1870878



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2020-755b4f2613 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-755b4f2613

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1871053] perl-Module-Load-Conditional-0.74 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1871053



--- Comment #11 from Fedora Update System  ---
FEDORA-MODULAR-2020-755b4f2613 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-755b4f2613

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1870878] perl-Module-CoreList-5.20200820 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1870878



--- Comment #11 from Fedora Update System  ---
FEDORA-MODULAR-2020-131bafc061 has been pushed to the Fedora 31 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-131bafc061

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1871053] perl-Module-Load-Conditional-0.74 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1871053

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-Load-Conditiona |perl-Module-Load-Conditiona
   |l-0.74-1.fc33   |l-0.74-1.fc33
   |perl-Module-Load-Conditiona |perl-Module-Load-Conditiona
   |l-0.74-1.fc31   |l-0.74-1.fc31
   ||perl-Module-Load-Conditiona
   ||l-0.74-1.fc32



--- Comment #10 from Fedora Update System  ---
FEDORA-2020-d47661bf9a has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1870878] perl-Module-CoreList-5.20200820 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1870878

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
   |0820-1.fc33 |0820-1.fc33
   |perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
   |0820-1.fc31 |0820-1.fc31
   ||perl-Module-CoreList-5.2020
   ||0820-1.fc32



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-1e54e92bc5 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1870878] perl-Module-CoreList-5.20200820 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1870878

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
   |0820-1.fc33 |0820-1.fc33
   ||perl-Module-CoreList-5.2020
   ||0820-1.fc31
 Resolution|--- |ERRATA
Last Closed||2020-09-01 19:26:07



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-a58110a2db has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1871053] perl-Module-Load-Conditional-0.74 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1871053

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version|perl-Module-Load-Conditiona |perl-Module-Load-Conditiona
   |l-0.74-1.fc33   |l-0.74-1.fc33
   ||perl-Module-Load-Conditiona
   ||l-0.74-1.fc31
 Resolution|--- |ERRATA
Last Closed||2020-09-01 19:26:09



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-edd8d15a38 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 33 blocker status

2020-09-01 Thread Miroslav Suchý

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

2020-09-01 Thread Miro Hrončok


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

2020-09-01 Thread Tom Hughes via devel


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

2020-09-01 Thread Andreas Tunek

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

2020-09-01 Thread Robbie Harwood

"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

2020-09-01 Thread Richard W.M. Jones

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

2020-09-01 Thread Adam Williamson

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

2020-09-01 Thread Tony Asleson

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

2020-09-01 Thread kevin

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)

2020-09-01 Thread Chris Murphy

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

2020-09-01 Thread Miro Hrončok


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

2020-09-01 Thread Jerry James

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

2020-09-01 Thread Jeff Law

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

2020-09-01 Thread Richard W.M. Jones

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

2020-09-01 Thread Robbie Harwood

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)

2020-09-01 Thread Ben Cotton

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

2020-09-01 Thread rawhide

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

2020-09-01 Thread Michael Catanzaro



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

2020-09-01 Thread Dan Horák

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

2020-09-01 Thread Michael Catanzaro



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

2020-09-01 Thread Tony Asleson

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

2020-09-01 Thread Fedora Rawhide Report

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

2020-09-01 Thread Greg Hellings

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)

2020-09-01 Thread Zbigniew Jędrzejewski-Szmek

 

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

2020-09-01 Thread Florian Weimer

* 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

2020-09-01 Thread Florian Weimer

* 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

2020-09-01 Thread Nico Kadel-Garcia

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

[Bug 1874459] New: perl-Net-Whois-Raw-2.99031 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1874459

Bug ID: 1874459
   Summary: perl-Net-Whois-Raw-2.99031 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-Whois-Raw
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.99031
Current version/release in rawhide: 2.99.030-1.fc34
URL: http://search.cpan.org/dist/Net-Whois-Raw/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/6677/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-01 Thread Kamil Paral

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

[Bug 1874449] New: Upgrade perl-Type-Tiny to 1.010005

https://bugzilla.redhat.com/show_bug.cgi?id=1874449

Bug ID: 1874449
   Summary: Upgrade perl-Type-Tiny to 1.010005
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Type-Tiny
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.010004 version. Upstream released 1.010005. When you
have free time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1873854] perl-Test-Dependencies-0.28 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1873854

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version|perl-Test-Dependencies-0.24 |perl-Test-Dependencies-0.28
   |-4.fc34 |-1.fc34




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1874173] perl-PDF-API2-2.038 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1874173

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-PDF-API2-2.038-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2020-09-01 11:21:00




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: python-versioneer: no version information in github archives?

2020-09-01 Thread Ankur Sinha

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

[Bug 1871053] perl-Module-Load-Conditional-0.74 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1871053



--- Comment #8 from Fedora Update System  ---
FEDORA-MODULAR-2020-131bafc061 has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-131bafc061


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1870878] perl-Module-CoreList-5.20200820 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1870878



--- Comment #7 from Fedora Update System  ---
FEDORA-MODULAR-2020-131bafc061 has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-131bafc061


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1870878] perl-Module-CoreList-5.20200820 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1870878

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



--- Comment #6 from Fedora Update System  ---
FEDORA-MODULAR-2020-755b4f2613 has been submitted as an update to Fedora 32
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-755b4f2613


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1871053] perl-Module-Load-Conditional-0.74 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1871053

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



--- Comment #7 from Fedora Update System  ---
FEDORA-MODULAR-2020-755b4f2613 has been submitted as an update to Fedora 32
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-755b4f2613


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: [golang packaging] how to get files from source tarball

2020-09-01 Thread Nicolas Mailhot via devel


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

2020-09-01 Thread Aoife Moloney

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)

2020-09-01 Thread Frantisek Zatloukal

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?

2020-09-01 Thread Stephan Bergmann

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

2020-09-01 Thread Roberto Ragusa


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

[Bug 1874173] perl-PDF-API2-2.038 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1874173

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

2020-09-01 Thread Petr Pisar

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

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.

-- 
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 Monday, August 31, 2020 1:39:37 PM MST Michael Catanzaro wrote:
> 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
> 
> 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

Michael,

The file is /etc/nsswitch.conf.


-- 
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: Switching package to fragmented default configuration