Re: Is Pagure openid login broken?

[Richard W.M. Jones]

On Thu, Mar 25, 2021 at 08:49:16PM +0200, Alexander Bokovoy wrote:
> On to, 25 maalis 2021, Richard W.M. Jones wrote:
> >On Thu, Mar 25, 2021 at 01:30:56PM -0400, Matthew Miller wrote:
> >>On Thu, Mar 25, 2021 at 05:10:47PM +, Richard W.M. Jones wrote:
> >>> https://pagure.io/login/?next=https://pagure.io/
> >>>
> >>> It says:
> >>>
> >>> "No email address was returned by your OpenID provider, this
> >>> information is mandatory for pagure"
> >>
> >>Yeah. I'm seeing this too when testing in a private window. Since I am
> >>logged in, I'll file the issue.
> >
> >Just now (a few seconds ago) it "fixed itself" and worked.
> >I don't know why and I suppose it's still a bug so thanks
> >for filing one.
> 
> If I understand it correctly, you caught a state in the middle of
> upgrades. Ipsilon IdP was actually reconfigured to use FreeIPA-provided
> data and some of attribute mappings did change which required
> modifications.

Thanks - it is working now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is Pagure openid login broken?

[Alexander Bokovoy]

On to, 25 maalis 2021, Richard W.M. Jones wrote:

On Thu, Mar 25, 2021 at 01:30:56PM -0400, Matthew Miller wrote:

On Thu, Mar 25, 2021 at 05:10:47PM +, Richard W.M. Jones wrote:
> https://pagure.io/login/?next=https://pagure.io/
>
> It says:
>
> "No email address was returned by your OpenID provider, this
> information is mandatory for pagure"

Yeah. I'm seeing this too when testing in a private window. Since I am
logged in, I'll file the issue.


Just now (a few seconds ago) it "fixed itself" and worked.
I don't know why and I suppose it's still a bug so thanks
for filing one.


If I understand it correctly, you caught a state in the middle of
upgrades. Ipsilon IdP was actually reconfigured to use FreeIPA-provided
data and some of attribute mappings did change which required
modifications.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is Pagure openid login broken?

[Richard W.M. Jones]

On Thu, Mar 25, 2021 at 01:30:56PM -0400, Matthew Miller wrote:
> On Thu, Mar 25, 2021 at 05:10:47PM +, Richard W.M. Jones wrote:
> > https://pagure.io/login/?next=https://pagure.io/
> > 
> > It says:
> > 
> > "No email address was returned by your OpenID provider, this
> > information is mandatory for pagure"
> 
> Yeah. I'm seeing this too when testing in a private window. Since I am
> logged in, I'll file the issue.

Just now (a few seconds ago) it "fixed itself" and worked.
I don't know why and I suppose it's still a bug so thanks
for filing one.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora Accounts Migration & Production Rollout Update: Day 1.5/2 +1

[Aoife Moloney]

Hi Everyone,

The title means that we are 1.5 days into our original planned disruption
period but some of the configurations were more complex and has resulted in
our team falling behind on completion.
We are still actively working on the production deployment of the new
Fedora Accounts System, but we believe you will be experiencing disruptions
for a minimum further 24 hours. Newest disruption time ending should be
around 1800 UTC on Friday 26th March.

We do apologise for the disruptions and loss of access you may be
experiencing in services you are trying to login to.

Currently the following services should be unaffected:
bodhi.fedoraproject.org
teams.fedoraproject.org
ask.fedoraproject.org
bugzilla.redhat.com (using SAML)
secondary.fpo
fedora wiki

We are also using https://status.fedoraproject.org/ for updates but the
going is slow so please bear with us.
If you cannot login to any service for Fedora, we recommend clearing
cookies/cache, waiting for up to one hour and retrying your login then. If
the issue persists, please open a ticket on
https://pagure.io/fedora-infrastructure/issues and our team will get to it
over the coming days.
Our team is working in IRC channel #fedora-aaa but we would ask you to file
tickets rather than report them there please.

Any and all help on this migration is most welcome and we would again like
to offer our sincerest thanks to the people from all over the world and
across multiple communities, not just Fedora, who have been helping our
team with this deployment and migration.

We hope to complete the most critical pieces of work by Friday 1800 UTC  -
the end is in sight so thank you for your patience through this time!


Kindest regards,
Aoife & the Fedora Accounts Team

-- 

Aoife Moloney

Product Owner

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is Pagure openid login broken?

[Fabio Valentini]

On Thu, Mar 25, 2021 at 6:31 PM Matthew Miller  wrote:
>
> On Thu, Mar 25, 2021 at 05:10:47PM +, Richard W.M. Jones wrote:
> > https://pagure.io/login/?next=https://pagure.io/
> >
> > It says:
> >
> > "No email address was returned by your OpenID provider, this
> > information is mandatory for pagure"
>
> Yeah. I'm seeing this too when testing in a private window. Since I am
> logged in, I'll file the issue.

I'm having the same issue on both pagure.io and src.fedoraproject.org.
Feel free to quote me on that :)

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is Pagure openid login broken?

[Matthew Miller]

On Thu, Mar 25, 2021 at 05:10:47PM +, Richard W.M. Jones wrote:
> https://pagure.io/login/?next=https://pagure.io/
> It says:
> "No email address was returned by your OpenID provider, this
> information is mandatory for pagure"

In case you weren't aware, this is likely a glitch resulting from the
in-progress transition to the new auth system:

* 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/KLKFTMMARTTJWE2DVD4VGASJUKIWKMJJ/

* 
https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/message/JGVRX7CSXSDJ2MV5TJNYPCGVWWI5XSNB/


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is Pagure openid login broken?

[Matthew Miller]

On Thu, Mar 25, 2021 at 05:10:47PM +, Richard W.M. Jones wrote:
> https://pagure.io/login/?next=https://pagure.io/
> 
> It says:
> 
> "No email address was returned by your OpenID provider, this
> information is mandatory for pagure"

Yeah. I'm seeing this too when testing in a private window. Since I am
logged in, I'll file the issue.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is Pagure openid login broken?

[Richard W.M. Jones]

On Thu, Mar 25, 2021 at 01:13:15PM -0400, Neal Gompa wrote:
> Could you please file an issue about that here:
> https://pagure.io/fedora-infrastructure/issues ?

Since I can't log in... no.

Rich.

> On Thu, Mar 25, 2021 at 1:11 PM Richard W.M. Jones  wrote:
> >
> >
> > https://pagure.io/login/?next=https://pagure.io/
> >
> > It says:
> >
> > "No email address was returned by your OpenID provider, this
> > information is mandatory for pagure"
> >
> > which I cannot find anything by search.  I've cleared cookies and all
> > that.  I'm assuming my "OpenID provider" is
> > https://accounts.fedoraproject.org/user/rjones/ which does have an
> > email address associated.
> >
> > 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
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> 
> 
> 
> -- 
> 真実はいつも一つ！/ 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is Pagure openid login broken?

[Neal Gompa]

Could you please file an issue about that here:
https://pagure.io/fedora-infrastructure/issues ?

On Thu, Mar 25, 2021 at 1:11 PM Richard W.M. Jones  wrote:
>
>
> https://pagure.io/login/?next=https://pagure.io/
>
> It says:
>
> "No email address was returned by your OpenID provider, this
> information is mandatory for pagure"
>
> which I cannot find anything by search.  I've cleared cookies and all
> that.  I'm assuming my "OpenID provider" is
> https://accounts.fedoraproject.org/user/rjones/ which does have an
> email address associated.
>
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
真実はいつも一つ！/ 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Is Pagure openid login broken?

[Richard W.M. Jones]

https://pagure.io/login/?next=https://pagure.io/

It says:

"No email address was returned by your OpenID provider, this
information is mandatory for pagure"

which I cannot find anything by search.  I've cleared cookies and all
that.  I'm assuming my "OpenID provider" is
https://accounts.fedoraproject.org/user/rjones/ which does have an
email address associated.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Currently, we are trying to stay away from the compat package and with the
help of other package maintainers trying to fix the failures. We will give
time to react accordingly and see other possible steps in a few weeks time.

Currently multiple FTBFS bugs in bugzilla were created according to
autoconf-2.71. More information available here:

https://fedoraproject.org/wiki/Changes/Autoconf_271

Ondrej

On Fri, Mar 19, 2021 at 5:59 PM Patrik Novotny  wrote:

> I'd advocate strongly against a compat package.
>
> The whole point of the change is to push the move to the new autoconf
> upstream release. Not the availability of autoconf 2.71 to the end user.
> For that, we would do much better with providing the end users with a
> modular release, I think.
>
> As for the argument of other distributions, Fedora has always been an
> early adopter. If we will create a compat package providing the 2.69
> version, what's the point of moving to autoconf 2.71 (maybe over providing
> a modular build) anyway?
>
> What I would argue is that we should make an effort to fully move to the
> new version of autoconf, and postpone the change if we find out that it is
> not doable in time for F35. Historically, it took some effort to mitigate
> providing compat packages of autoconf, and experience tells us that when we
> do, the motivation to fix packages incompatible with the new version
> virtually disappears.
>
> IMO, the only scenario, where a compat package would make sense, is if we
> were to push for the removal of this compat package right from the moment
> of it's introduction. In that case, the only real benefit of completing the
> Autoconf 2.71 change, would be *a little* easier process of making
> necessary changes to now incompatible packages in exchange for any real
> motivation to actually do so. If the point of this change is the
> availability of autoconf 2.71 to the end-user, I would argue that a modular
> build would be a much cleaner approach.
>
> We should push for this change to be done the proper way, not for the
> possibility of making a slow progress over long period of time for the
> price of duplicating packages. If we need more time for that, this change
> should be postponed.
>
> On Fri, Mar 12, 2021 at 4:27 PM Jonathan Wakely 
> wrote:
>
>> On 09/03/21 09:15 +, Tomasz Kłoczko wrote:
>> >Some time ago gcc, binutils IIRC received an update for ac 2.71 so at
>> least
>> >those two should be by now off-the-table (Am I right?).
>>
>> No. GCC has a hard requirement on autoconf-2.69, but the Fedora
>> package doesn't need to run autoconf for it (that happens when
>> upstream creates the snapshot tarball).
>>
>> I'm not sure about binutils, but I would be very surprised if it is
>> different from GCC.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
>
> --
> Patrik Novotný
> Associate Software Engineer
> Red Hat
> panov...@redhat.com
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1943227] New: perl-Perl-Metrics-Simple-1.0.0 is available

[bugzilla]

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

Bug ID: 1943227
   Summary: perl-Perl-Metrics-Simple-1.0.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Perl-Metrics-Simple
  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: 1.0.0
Current version/release in rawhide: 0.19-1.fc35
URL: http://search.cpan.org/dist/Perl-Metrics-Simple/

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/3224/


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1943227] perl-Perl-Metrics-Simple-1.0.0 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/authors/id/M/MA/MATISSE/Perl-Metrics-Simple-1.0.0.tar.gz
to ./Perl-Metrics-Simple-1.0.0.tar.gz


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: autoconf FTBFS bugs being filed but no obvious build failure

[Ondrej Dubaj]

Not yet, will keep you updated when it will be created.

On Thu, Mar 25, 2021 at 3:34 PM Gwyn Ciesla via devel <
devel@lists.fedoraproject.org> wrote:

> Does the koji side tag exist yet?
>
> --
> Gwyn Ciesla
> she/her/hers
> 
> in your fear, seek only peace
> in your fear, seek only love
> -d. bowie
>
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, March 25, 2021 8:02 AM, Ondrej Dubaj 
> wrote:
>
> Hi,
>
> there might be some "false negatives". If the packages are successfully
> built in the given copr, please close the trackers. In most cases the FTBFS
> bugs are relevant.
>
> Thank you.
>
> Ondrej
>
> On Thu, Mar 25, 2021 at 1:57 PM Richard W.M. Jones 
> wrote:
>
>>
>> eg:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1943008
>> "coccinelle: FTBFS with upcoming autoconf-2.71"
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1943041
>> "ocaml-curses: FTBFS with upcoming autoconf-2.71"
>>
>> I followed the links given in both, but as far as I can tell the
>> builds succeeded in both cases.  Unless I'm looking at the wrong thing -
>> it's hard to tell.
>>
>> Rich.
>>
>> --
>> Richard Jones, Virtualization Group, Red Hat
>> http://people.redhat.com/~rjones
>> Read my programming and virtualization blog: http://rwmj.wordpress.com
>> libguestfs lets you edit virtual machines.  Supports shell scripting,
>> bindings from many languages.  http://libguestfs.org
>>
>> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Thursday's FPC Meeting (2021-03-25 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-03-11 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2021-03-25 09:00 PDT  US/Pacific
2021-03-25 12:00 EDT  --> US/Eastern <--
2021-03-25 16:00 GMT  Europe/London 
2021-03-25 16:00 UTC  UTC   
2021-03-25 17:00 CET  Europe/Berlin 
2021-03-25 17:00 CET  Europe/Paris  
2021-03-25 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2021-03-26 00:00 HKT  Asia/Hong_Kong
2021-03-26 00:00 +08  Asia/Singapore
2021-03-26 01:00 JST  Asia/Tokyo
2021-03-26 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

= New business =

#topic #1055 can't navigate to pkg instructions from fedoraproject.org
.fpc 1055
https://pagure.io/packaging-committee/issue/1055

#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058

= Followup Issues =

#topic #886 Enable BRP for detecting RPATH 
.fpc 886
https://pagure.io/packaging-committee/issue/886

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Font-AFM] PR #3: use NimbusSans-Bold font in test instead of phvr

[Tom Callaway]

spot merged a pull-request against the project: `perl-Font-AFM` that you are 
following.

Merged pull-request:

``
use NimbusSans-Bold font in test instead of phvr
``

https://src.fedoraproject.org/rpms/perl-Font-AFM/pull-request/3
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Michael Catanzaro]

On Thu, Mar 25 2021 at 09:26:19 AM -0500, Michael Catanzaro 
 wrote:
For now, keep nss-myhostname at the start of the line, right after 
files. We will probably need to find a way to either (a) fix 
systemd-resolved to handle mDNS properly, so we can move it after 
nss-resolve, where it really belongs, or (b) move nss-myhostname in 
front of nss-mdns4_minimal.


OK, I've reported https://bugzilla.redhat.com/show_bug.cgi?id=1943199. 
It requires further discussion though, to see if the systemd package 
maintainers agree.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Robert Marcano via devel]

On 3/25/21 10:21 AM, Michael Catanzaro wrote:


On Thu, Mar 25 2021 at 08:37:03 AM -0400, Robert Marcano via devel 
 wrote:

IMHO the fedora name should be always resolvable the same way as
localhost or just remove it. It is not right thsat fedora is being
resolved only while the DHCP server isn't assigning you a new hostname.
You never know when a DHCP server will decide to send you one,
especially if you move around many WiFi hotspots


The problem is not specific to the name "fedora" though. Our intended 
behavior is to resolve the local hostname locally, without doing any 
DNS, regardless of what its name is. This broke in Fedora 33 and you're 
just the first person to notice and complain afaik.


Thank for looking at it. Without the broken VPN DNS and Firefox doing 
some weird lookup at startup for the hostname I would have never noticed it.


I wonder if the Firefox thing has to do with their policies. Apparently 
they have to be processed very early at startup and maybe there is 
something in there slowing things down, but that would be another bug 
than this one.




So editing /etc/hosts is not the right solution. We need to change our 
NSS configuration. I'll send another mail about this.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Jerry James]

On Wed, Mar 24, 2021 at 7:51 PM Robert Marcano via devel
 wrote:
> Maybe changing the default hostname to fedora wasn't a good idea after
> all, or at least fedora should be added to the default /etc/hosts.

Note that setting the hostname to "fedora" also led to log spam, for
me at least:

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

I am interested to learn whether that happened to anybody else.
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Michael Catanzaro]

On Thu, Mar 25 2021 at 09:26:19 AM -0500, Michael Catanzaro 
 wrote:
We spent a long time thinking about the order the NSS modules should 
be listed, but then made a last-minute change to move 
nss-mdns4_minimal forward in order to work around a bug with 
systemd-resolved not handling mDNS properly: 
https://bugzilla.redhat.com/show_bug.cgi?id=1867830.


Looking at that bug, it seems to be a NetworkManager issue. I'm not 
familiar with mDNS and actually don't know how it's supposed to work


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: autoconf FTBFS bugs being filed but no obvious build failure

[Gwyn Ciesla via devel]

Does the koji side tag exist yet?

-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, March 25, 2021 8:02 AM, Ondrej Dubaj  wrote:

> Hi,
> 

> there might be some "false negatives". If the packages are successfully built 
> in the given copr, please close the trackers. In most cases the FTBFS bugs 
> are relevant.
> 

> Thank you.
> 

> Ondrej
> 

> On Thu, Mar 25, 2021 at 1:57 PM Richard W.M. Jones  wrote:
> 

> > eg:
> > 

> > https://bugzilla.redhat.com/show_bug.cgi?id=1943008
> > "coccinelle: FTBFS with upcoming autoconf-2.71"
> > 

> > https://bugzilla.redhat.com/show_bug.cgi?id=1943041
> > "ocaml-curses: FTBFS with upcoming autoconf-2.71"
> > 

> > I followed the links given in both, but as far as I can tell the
> > builds succeeded in both cases.  Unless I'm looking at the wrong thing -
> > it's hard to tell.
> > 

> > Rich.
> > 

> > --
> > Richard Jones, Virtualization Group, Red Hat 
> > http://people.redhat.com/~rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > libguestfs lets you edit virtual machines.  Supports shell scripting,
> > bindings from many languages.  http://libguestfs.org

signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Michael Catanzaro]

OK, so then the problem here is avahi, or more specifically, that 
nss-mdns4_minimal is listed before nss-resolve and nss-myhostname. We 
need nss-myhostname to come before nss-mdns4_minimal. Drat. We spent a 
long time thinking about the order the NSS modules should be listed, 
but then made a last-minute change to move nss-mdns4_minimal forward in 
order to work around a bug with systemd-resolved not handling mDNS 
properly: https://bugzilla.redhat.com/show_bug.cgi?id=1867830. When we 
moved nss-mdns4_minimal, we should have moved nss-myhostname too.


This is a little hard to fix because the scriptlets that write this 
configuration are fragile, maintained in multiple places (systemd and 
avahi), and depend on assumptions about the previous state of the file 
(created by authselect normally, but possibly also by the glibc 
package). So the way our RPMs configure this line is really quite 
fragile unfortunately. We will have to discuss the best way to fix 
things.


For now, keep nss-myhostname at the start of the line, right after 
files. We will probably need to find a way to either (a) fix 
systemd-resolved to handle mDNS properly, so we can move it after 
nss-resolve, where it really belongs, or (b) move nss-myhostname in 
front of nss-mdns4_minimal.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Michael Catanzaro]

On Thu, Mar 25 2021 at 08:37:03 AM -0400, Robert Marcano via devel 
 wrote:

IMHO the fedora name should be always resolvable the same way as
localhost or just remove it. It is not right thsat fedora is being
resolved only while the DHCP server isn't assigning you a new 
hostname.

You never know when a DHCP server will decide to send you one,
especially if you move around many WiFi hotspots


The problem is not specific to the name "fedora" though. Our intended 
behavior is to resolve the local hostname locally, without doing any 
DNS, regardless of what its name is. This broke in Fedora 33 and you're 
just the first person to notice and complain afaik.


So editing /etc/hosts is not the right solution. We need to change our 
NSS configuration. I'll send another mail about this.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

gcompris-qt license change

[Andrea Musuruane]

gcompris-qt changed license from GPLv3+ to AGPLv3 in version 1.1 because
they used a library for analog electricity activity under AGPLv3 causing
the whole software to be licensed under it.

Regards,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: autoconf FTBFS bugs being filed but no obvious build failure

[Ondrej Dubaj]

Hi,

there might be some "false negatives". If the packages are successfully
built in the given copr, please close the trackers. In most cases the FTBFS
bugs are relevant.

Thank you.

Ondrej

On Thu, Mar 25, 2021 at 1:57 PM Richard W.M. Jones 
wrote:

>
> eg:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1943008
> "coccinelle: FTBFS with upcoming autoconf-2.71"
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1943041
> "ocaml-curses: FTBFS with upcoming autoconf-2.71"
>
> I followed the links given in both, but as far as I can tell the
> builds succeeded in both cases.  Unless I'm looking at the wrong thing -
> it's hard to tell.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

autoconf FTBFS bugs being filed but no obvious build failure

[Richard W.M. Jones]

eg:

https://bugzilla.redhat.com/show_bug.cgi?id=1943008
"coccinelle: FTBFS with upcoming autoconf-2.71"

https://bugzilla.redhat.com/show_bug.cgi?id=1943041
"ocaml-curses: FTBFS with upcoming autoconf-2.71"

I followed the links given in both, but as far as I can tell the
builds succeeded in both cases.  Unless I'm looking at the wrong thing -
it's hard to tell.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Robert Marcano via devel]

On 3/24/21 9:51 PM, Robert Marcano wrote:
Currently I am connecting to a VPN that provides a few DNS search 
entries. One of these domains on the search path is having DNS 
resolution problems. This is not per se the the problem I am  writing 
this email for.


The problem is that starting Firefox and Thunderbird take a long time, 
it took time to detect the DNS resolution problem was the origin of 
these timeouts. I am not using that domain that is having resolution 
problems.


The real culprit is the default `fedora` hostname, instead of localhost. 
Starting a Wireshark capture there are DNS searches for 
fedora.domain_failing.tld, when starting Firefox and Thunderbird. The 
presence of the search path on generated /etc/resolv.conf isn't the 
cause of these DNS searches, I edited them out while the VPN was still 
active.


Even 'ping fedora' start doing these searches with the search paths 
appended. 'ping localhost' doesn't do that. The only workaround to this 
issue is to add fedora to the localhost entries on /etc/hosts.


This in some way is a DNS leak, even on a VPN with perfectly working DNS 
resolution, the fedora name should not be searched on these domains 
until I am using the fedora full hostname on these domains. Even worse 
when simply starting applications like Firefox o Thunderbird.


Maybe changing the default hostname to fedora wasn't a good idea after 
all, or at least fedora should be added to the default /etc/hosts.


About the default fedora transient hostname nchange. This has caused 
more problems that really solved.


Sometime ago the default HOSTNAME environment variable was changed to 
use in /etc/profile


  HOSTNAME=`/usr/bin/hostnamectl --transient`

This didn't cause any problems initially because the the default was 
localhost.localdomain, but now that is fedora. If you reach the desktop 
before plugin in your laptop to the network and your network DHCP server 
assigns you a hostname, you get a entire session where the HOSTNAME 
isn't resolvable, because fedora is only resolvable when the transient 
host name was set as fedora, but it was overriden by the DHCP server.


Tilix was one of the programs with problems with this, you get an 
annoying warning. I solved this by adding HOSTNAME=`hostname` to .bashrc


IMHO the fedora name should be always resolvable the same way as 
localhost or just remove it. It is not right thsat fedora is being 
resolved only while the DHCP server isn't assigning you a new hostname. 
You never know when a DHCP server will decide to send you one, 
especially if you move around many WiFi hotspots

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Robert Marcano via devel]

On 3/25/21 7:30 AM, Petr Menšík wrote:

Hi,

I would guess your domainname is not (none), and hostname -f value is
fedora.domain_failing.tld. One of fixes might be to change hostname of
the machine to not contain domains suffix. Then only explicitly
configured search would apply.


No:

# hostname -f
fedora



On 3/25/21 2:51 AM, Robert Marcano via devel wrote:

Currently I am connecting to a VPN that provides a few DNS search
entries. One of these domains on the search path is having DNS
resolution problems. This is not per se the the problem I am  writing
this email for.

The problem is that starting Firefox and Thunderbird take a long time,
it took time to detect the DNS resolution problem was the origin of
these timeouts. I am not using that domain that is having resolution
problems.

Would dig fedora.domain_failing.tld take long before VPN is
estabilished? Does it timeout when connecting or after connected?
Timeout might mean some of connection provided servers does not respond
or route to it does not work. Even searches should mean just more
packets, not visibly longer delay.


It doesn't take long because fedora.domain_failing.tld fails fast on the 
default network DNS, domain_failing.tld is a domain only available on 
the VPN


The real culprit is the default `fedora` hostname, instead of localhost.
Starting a Wireshark capture there are DNS searches for
fedora.domain_failing.tld, when starting Firefox and Thunderbird. The
presence of the search path on generated /etc/resolv.conf isn't the
cause of these DNS searches, I edited them out while the VPN was still
active.

Try not commenting it out, but override default system value in
/etc/resolv.conf:
search .


Even 'ping fedora' start doing these searches with the search paths
appended. 'ping localhost' doesn't do that. The only workaround to this
issue is to add fedora to the localhost entries on /etc/hosts.

That would be likely because localhost is in /etc/hosts, read by files
in nsswitch. But dns queries (if systemd-resolved is disabled) are
configured by /etc/resolv.conf.


This in some way is a DNS leak, even on a VPN with perfectly working DNS
resolution, the fedora name should not be searched on these domains
until I am using the fedora full hostname on these domains. Even worse
when simply starting applications like Firefox o Thunderbird.

Are you sure you do not have hostname set to FQDN? Have you tried
setting it to relative name (no dots)?


Maybe changing the default hostname to fedora wasn't a good idea after
all, or at least fedora should be added to the default /etc/hosts.

It should not be necessary unless fqdn is used as a hostname. "fedora"
value should be completely ok. But I guess even when connecting to VPN,
it should not timeout. DNS settings should be changed only after VPN is
connected and ready to forward packets. Are you sure no IP range
conflicts with used DNS servers?

Cheers,
Petr


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Robert Marcano via devel]

On 3/24/21 11:26 PM, Michael Catanzaro wrote:


Hi,

I have a couple different ideas of what could be going wrong. Let's test 
a few things. First, please run:


$ cat /etc/nsswitch.conf | grep hosts | tail -1

If it is our default configuration, it should say:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] 
myhostname dns


Exactly the same output, nsswitch.conf is pointing to 
/etc/authselect/nsswitch.conf default




Now, see what happens if you disable systemd-resolved:

$ sudo systemctl stop systemd-resolved.service


This doesn't properly disable systemd-resolved, There is a DNS 
resolution error or two and then the service is autostarted (probably 
socket activation)


I entirely disabled it by changing dns=default in NetworkManager and 
renaming the /etc/resolv.conf symlink to another name.




Does the bug go away? If so, it's likely a systemd-resolved bug to be 
fixed. (Reenable systemd-resolved with 'sudo systemctl start 
systemd-resolved.service'.)


No, the bug dosn't go away. The fedora name is still searched on all 
search domains (traced bu wireshark) and not a simple direct local 
response like happens with localhost





If the bug does NOT go away, then let's test one more thing: please edit 
/etc/authselect/user-nsswitch.conf as root and change the hosts line to 
look like this:


hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve 
[!UNAVAIL=return] dns


Then run:

$ sudo authselect apply-changes


With this the bug goes away.



Does the bug go away? I think that should almost certainly "fix" it. If 
so, you have a good workaround, and we know the problem must be caused 
by avahi, and we should reconsider our NSS configuration. But if the bug 
does not go away after this big hammer, then it must be a 
Firefox/Thunderbird bug, because if they try to resolve anything that 
doesn't exactly match the local hostname, then of course we have to do 
some DNS.


Notice that it isn't a Firefox and Thunderbird issue. 'ping fedora' have 
these long DNS timeouts looking fedora on the search domains. I agree 
that it is weird that these applications are doing lookups with the 
hostname, but ping should not be doing these either with fedora, exactly 
like localhost doesn't ends up as queries on the search domains.




I'm interested to see the your results,

Michael



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[Petr Menšík]

Hi,

I would guess your domainname is not (none), and hostname -f value is
fedora.domain_failing.tld. One of fixes might be to change hostname of
the machine to not contain domains suffix. Then only explicitly
configured search would apply.

On 3/25/21 2:51 AM, Robert Marcano via devel wrote:
> Currently I am connecting to a VPN that provides a few DNS search
> entries. One of these domains on the search path is having DNS
> resolution problems. This is not per se the the problem I am  writing
> this email for.
> 
> The problem is that starting Firefox and Thunderbird take a long time,
> it took time to detect the DNS resolution problem was the origin of
> these timeouts. I am not using that domain that is having resolution
> problems.
Would dig fedora.domain_failing.tld take long before VPN is
estabilished? Does it timeout when connecting or after connected?
Timeout might mean some of connection provided servers does not respond
or route to it does not work. Even searches should mean just more
packets, not visibly longer delay.
> 
> The real culprit is the default `fedora` hostname, instead of localhost.
> Starting a Wireshark capture there are DNS searches for
> fedora.domain_failing.tld, when starting Firefox and Thunderbird. The
> presence of the search path on generated /etc/resolv.conf isn't the
> cause of these DNS searches, I edited them out while the VPN was still
> active.
Try not commenting it out, but override default system value in
/etc/resolv.conf:
search .
> 
> Even 'ping fedora' start doing these searches with the search paths
> appended. 'ping localhost' doesn't do that. The only workaround to this
> issue is to add fedora to the localhost entries on /etc/hosts.
That would be likely because localhost is in /etc/hosts, read by files
in nsswitch. But dns queries (if systemd-resolved is disabled) are
configured by /etc/resolv.conf.
> 
> This in some way is a DNS leak, even on a VPN with perfectly working DNS
> resolution, the fedora name should not be searched on these domains
> until I am using the fedora full hostname on these domains. Even worse
> when simply starting applications like Firefox o Thunderbird.
Are you sure you do not have hostname set to FQDN? Have you tried
setting it to relative name (no dots)?
> 
> Maybe changing the default hostname to fedora wasn't a good idea after
> all, or at least fedora should be added to the default /etc/hosts.
It should not be necessary unless fqdn is used as a hostname. "fedora"
value should be completely ok. But I guess even when connecting to VPN,
it should not timeout. DNS settings should be changed only after VPN is
connected and ready to forward packets. Are you sure no IP range
conflicts with used DNS servers?

Cheers,
Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FYI: IETF deprecates TLS 1.0 + 1.1

[Tom Hughes via devel]

On 25/03/2021 09:59, Marius Schwarz wrote:


the IETF has now deprecated TLS 1.0 and 1.1 .

https://datatracker.ietf.org/doc/rfc8996/

Do we plan an official Old-TLS-Deactivation date or do gnutls and 
openssl decide when it's time to deactivate them?


They were removed from the default crypto policy in Fedora 33:

  https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

FYI: IETF deprecates TLS 1.0 + 1.1

[Marius Schwarz]

Hi,

the IETF has now deprecated TLS 1.0 and 1.1 .

https://datatracker.ietf.org/doc/rfc8996/

Do we plan an official Old-TLS-Deactivation date or do gnutls and 
openssl decide when it's time to deactivate them?


Best regards,
Marius
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-32-20210325.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-32-20210324.0):

ID: 828916  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/828916
ID: 828923  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/828923

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1942851] New: Upgrade perl-File-Which to 1.24

[bugzilla]

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

Bug ID: 1942851
   Summary: Upgrade perl-File-Which to 1.24
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-File-Which
  Assignee: spo...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.23 version. Upstream released 1.24. 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1942850] New: Upgrade perl-File-Touch to 0.12

[bugzilla]

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

Bug ID: 1942850
   Summary: Upgrade perl-File-Touch to 0.12
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-File-Touch
  Assignee: andrea.v...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: andrea.v...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.11 version. Upstream released 0.12. 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1942849] perl-DateTime-Calendar-Julian-0.104 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Unable to resolve the hostname for one of the package's Source URLs


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1942849] New: perl-DateTime-Calendar-Julian-0.104 is available

[bugzilla]

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

Bug ID: 1942849
   Summary: perl-DateTime-Calendar-Julian-0.104 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime-Calendar-Julian
  Keywords: FutureFeature, Triaged
  Assignee: spo...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.104
Current version/release in rawhide: 0.103-2.fc34
URL: http://search.cpan.org/dist/DateTime-Calendar-Julian/

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/11936/


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20210325.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20210324.0):

ID: 828895  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/828895
ID: 828902  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/828902

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] Re: Please have look at One-Time Password password policy

[thierry bordaz]

On 3/25/21 3:20 AM, William Brown wrote:



On 25 Mar 2021, at 12:00, Mark Reynolds  wrote:


On 3/24/21 8:32 PM, William Brown wrote:

I think maybe it could be easy to visualise it.


We have time going from past to future like:


past -> future


So we want a window of:

* When can the OTP start to be used?
* When is the OTP no longer able to be used?

So my thinking is:

past -> future
^  ^ ^
|  | |
otp created| |
otp valid from   |
  otp expire at


So I would say otp valid from and the otp expire should be *absolute* date 
times in UTC.


Hi William

Good idea of that graphic. I am sorry to be so slow to understand but still 
things are not clear.
There are the attributes of the password policy and the operational attribute 
of the user account.

I think you meant and I agree with you that operational attributes (in the user 
account) should be absolute date.
What is not clear to me is how to compute those operational attributes from the 
password policy.
I see three options:
• password policy contains absolute time (e.g. passwordOTPValidFromUTC) 
=> account.validFrom = policyValidFromUTC
• password policy contains a delay after OTP create/reset (e.g. 
passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
• password policy contains both and if both are set we should give the 
priority to one or the other
If a password policy is a stable entry, then they should not contain absolute 
time. If we imagine password policy created on purpose to do a bunch of 
registration, then that is okay if they contain absolute time.

Do you think we should support password policy with absolute time ?


No we should not store actual times in the config.  These time values need to 
live in the entry itself, just like passwordExpirationtime. Perhaps this is a 
good candidate to handle through the CLI (maybe even a new task that uses a 
filter, base, etc)?

I'm a bit confused about this answer but:

Theirry thought you wanted to set:


 dn: cn=config
 passwordOTPStartTime: 2021034578489754Z


But I was saying it should be in the entry, not cn=config, like how we use 
passwordExpirationtime:


 uid=mark,dc=example,dc=com
 passwordOTPStartTime: 2021034578489754Z

Yep, this is exactly what I meant :)



Mark


I think there are no "operational" attributes here. These should all be 
absolute dates, set on the entry. No calculation or whatever needed.


Thanks Mark, William for the clarification.
Actually OTP is an extension of the current password policy. So there 
are new attribute in the password policy entry and new (operational) 
attributes in the account entry.


I understand and agree that attributes (in the account entry) that 
represent a window of validity will be absolute time.


For example we will have, assuming that an admin reset the userpassword 
of 'uid=mark' at 10AM we will have


dn: cn=config
passwordMustChange: on
passwordOTPValidFromDelay: 1800
passwordOTPExpireDelay: 3600
passwordOTPMaxUse: 3


dn: uid=mark,dc=example,dc=com
userpassword: xxx
pwdOTPReset: true
pwdOTPUseCount: 0
pwdOTPValidFrom: 20210325103000Z
pwdOTPExpireAt: 2021032511Z

Meaning the user 'Mark' should complete his registration between 10:30AM 
and 11AM and he will be granted 3 tries to bind with the registration 
password and change his password


thanks
thierry



There is no policy at all. Basicly you just have a mechanic that sets on the 
account that this password is only valid in these time windows, and can only be 
used a maximum number of times.




Mark


—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia


--

389 Directory Server Development Team

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure