[Test-Announce] Fedora 33 Rawhide 20200529.n.2 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 33 Rawhide 20200529.n.2. 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

Notable package version changes:
anaconda - 20200522.n.0: anaconda-33.15-2.fc33.src, 20200529.n.2: 
anaconda-33.15-3.fc33.src
python-blivet - 20200522.n.0: python-blivet-3.2.2-1.fc33.src, 20200529.n.2: 
python-blivet-3.2.2-2.fc33.src
pyparted - 20200522.n.0: pyparted-3.11.5-1.fc33.src, 20200529.n.2: 
pyparted-3.11.5-2.fc33.src
pykickstart - 20200522.n.0: pykickstart-3.25-1.fc33.src, 20200529.n.2: 
pykickstart-3.25-2.fc33.src
lorax - 20200522.n.0: lorax-33.3-1.fc33.src, 20200529.n.2: lorax-33.3-2.fc33.src
pungi - 20200522.n.0: pungi-4.2.2-2.fc33.src, 20200529.n.2: 
pungi-4.2.2-3.fc33.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33

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_33_Rawhide_20200529.n.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200529.n.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200529.n.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200529.n.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200529.n.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200529.n.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200529.n.2_Security_Lab

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

[389-devel] 389 DS nightly 2020-05-30 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/30/report-389-ds-base-1.4.4.3-20200529git7b79b89.fc32.x86_64.html
___
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 1841510] [RFE] EPEL-8 branch for perl-Crypt-Random-Seed

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-fb765aaeb7 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fb765aaeb7

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 1841267] please build perl-Clipboard for epel8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-64d8621ef0 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-64d8621ef0

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 1841269] please build perl-Term-ShellUI for epel8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-690117dfc0 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-690117dfc0

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

Re: Fwd: Re: late generation of assemble code

[John M. Harris Jr]

On Friday, May 29, 2020 5:15:45 PM MST Colin Walters wrote:
> On Fri, May 29, 2020, at 8:01 PM, John M. Harris Jr wrote:
> 
> 
> > WebAssembly is just in web browsers. It's not for normal software you'd 
> > install with your package manager. Unless I'm missing something?
> 
> 
> You are indeed missing
> 
> https://webassembly.org/docs/non-web/
> https://wasi.dev/
> 
> More random links, and I'm sure others have better ones:
> 
> https://github.com/enarx/enarx/wiki/WebAssembly-(Wasm)
> https://deislabs.io/posts/introducing-krustlet/
> https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/
> https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html
> https://hacks.mozilla.org/2019/08/webassembly-interface-types/

How does this compare to LLVM IR in terms of performance? What software do you 
believe it would make sense to ship as WebAssembly? Would it actually be 
beneficial compared to shipping software normally?


With WebAssembly, it's getting to the point where I really just have to ask 
"Why?" when this sort of thing comes up. It seems that we're just looking for 
ways to overcomplicate things at this point, pulling in "Web" technologies for 
things that are surprisingly simple. Web browser vendors continue to surprise 
me with how overcomplicated these things are getting. I remember when web 
browsers didn't need gigabytes of RAM to function properly, when they didn't 
need to run in multiple processes.


-- 
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: Supporting hibernation in Workstation ed., draft 1

[John M. Harris Jr]

On Friday, May 29, 2020 5:25:23 PM MST Chris Murphy wrote:
> On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr 
> wrote:
> >
> >
> > I'm sorry, but this makes absolutely no sense.
> 
> 
> Disliking the story is not the same thing as it not making sense.
> There isn't much I can do about the former, but if you have a specific
> area where there is a lack of clarity, I'll try to clear it up.

It's not that I don't like anything about this, it just doesn't seem to match 
the reality of the situation.

> >You can test hibernation right
> > now, and it will work. When you boot back up, it'll have everything just
> > as you left it. What systems is it broken on, those with Secure Boot?
> 
> Not broken, disabled. That's the policy both upstream and in Fedora.

Then why not just re-enable it? Why in the world is it disabled? If it's 
disabled, why did it work when I ran `systemctl hibernate`? Why does it work 
with KDE Spin out of box?

> > I've just taken a Lenovo T500, installed GNOME Workstation and gone into
> > hibernation. It took about 30 seconds to boot back in, but I was right
> > where I left off. What exactly is broken, and for what portion of users?
> 
> 
> I don't know  the Lenovo T500 firmware setup defaults. If it conforms
> to Microsoft Windows (8 or later) hardware certification
> specifications, then UEFI Secure Boot is enabled by default. And it
> mean you changed the defaults to get the results you're experiencing,
> thereby disabling a  significant feature the Fedora invested
> significant resources to explicitly support.

The Lenovo T500 is one of the first or second generation EFI devices. The only 
settings that have been changed is the disabling of PXE and setting a boot 
settings password.  I have access to some newer hardware that has Secure Boot 
that I can test with. I'll go and snag one of those now, and get a test 
install of Workstation going.

I asked above, but  it wasn't answered, and your answer to this has me a bit 
confused. Is Secure Boot the issue that is blocking resume from working 
properly? If so, I can ensure that Secure Boot is enabled on the hardware that 
supports it, and try hibernation there.

Regardless, if that's the case, wouldn't it make more sense to keep 
hibernation available in the UI where it's supported well, the systems without 
Secure Boot? A trivial check for that could be false if BIOS, and false if 
efivars doesn't show that it was booted with secure boot.

-- 
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: new packages review tickets

[Jason Tibbitts]

I'll apologize in advance for rambling, but I've been kicking around
ideas in this space for very many years now.

> "SJS" == Stephen John Smoogen  writes:

SJS> Well it is quite clear we are doing something wrong and have been
SJS> for as long as the project has been going on.

It's true that we've basically always had a backlog of tickets.  To be
fair, it's not as bad now as it was at its worst.  I haven't looked at
the queue in a couple of years and while there are some familiar tickets
there (one is now over 14 years old) I see pretty much what I expect.

SJS> Package reviews are like dirty dishes and laundry to a lot of
SJS> people and there are always something they would rather do or HAVE
SJS> to than do it.  Until someone removes the Somebody Else's Problem
SJS> Field from it.. reviews will pile up.

Yes, but there are other factors.  For example, we almost never just say
"no", instead letting the tickets just sit there.  We must at some point
accept the fact that there are going to be pieces of software that
basically nobody cares about, and not say that absolutely everything has
to be part of the distribution proper.

Sometimes I wish we could separate out the different "domains" of
package acceptance and let different people (or even automated systems)
handle them.

For example, here's a dumb list:

1) Is the thing legally acceptable?
2) Does the thing build?
3) Does the package meet some minimal standard (installs without
dependency problems, doesn't obsolete glibc, doesn't drop junk all over
the filesystem, etc.)
4) Is the payload fit for purpose (software needs to run, content needs
to... be contenty, etc.)?
5) Is the packaging itself (specfile) maintainable (meets guidelines, etc.)?

If a script could drive by and say "yep, it still builds" every so
often, that would actually help quite a bit.  If someone could drive by 
and say "yep, the license stuff checks out" then that would free a
reviewer from having to do that.  (And back when I did reviews, I spent a
significant amount of time worrying about that.)

If I could run through, look at specfiles and red flag things which are
problematic without having to sign on to the entire process (wait for
builds, worry about licensing) then I might occasionally spend some time
doing that.

I wonder if it would be possible for review tickets to acquire a number
of flags instead of just the one fedora-review flag, and the package
would simply be acceptable when all of the flags are checked off.

And on a separate tack, I would love to see an alternate path to package
acceptance that goes through COPR.  So if a package (or stack of
packages) is functional and well-maintained in COPR, someone with
appropriate privileges could simply nominate it for inclusion in the
main repository.  Other folks could look, have a chance to comment, and
then if sufficient positive votes are collected, the repo is created.

I can see that being really incredibly useful for stacks of packages
(where the one desired packages has a whole tree of dependencies that
have to go in first).  Not only do these clog up the review queue and
make the situation look even more hopeless, but there are so many round
trips through the process that it's just incredibly painful.

And while I'm on a roll, is there any system at all that we could use
where I can look at a specfile and make comments on specific lines?  I
can do that in a PR in any forge; can we leverage that way of working
somehow?  Is there any crazy way that we could have new package
submissions be submitted as PRs against some base prototype package
repo, with the existing koji CI stuff automatically making sure that the
submission builds?

 - J<
___
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: Packages that failed to build with Python 3.9

[Kevin Fenzi]

On Fri, May 29, 2020 at 04:17:03PM -0700, Adam Williamson wrote:
> I fixed apsw and rebuilt calibre, which needed it. bugzilla2fedmsg

I looked at apsw also, but in 
https://bugzilla.redhat.com/show_bug.cgi?id=1840234
the maintainer wanted to wait for a new release which is prepping
upstream. 

Thanks for fixing it

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

[Test-Announce] Proposal to CANCEL: 2020-06-01 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting for Monday. We met
this week and I don't have anything urgent new this week.

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

BTW, if anyone's wondering about F33 blocker review meetings - there's
only a handful of proposed blockers ATM and I don't see a lot of value
in reviewing them right now, so I haven't been proposing meetings. If
anyone desperately wants to have one, yell :)

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: [External] Re: Supporting hibernation in Workstation ed., draft 1

[Mark Pearson]

> -Original Message-
> From: John M. Harris Jr 
> Sent: Friday, May 29, 2020 8:06 PM
> 
> On Friday, May 29, 2020 3:58:26 PM MST Chris Murphy wrote:
> > Hi,
> >
> > Fedora Workstation working group has been investigating the working
> > state of hibernation (suspend to disk) for about four months, and has
> > produced a draft status report on the findings so far. Present status,
> > impediments to support, and importantly, the specifics of how to
> > address those impediments, are described.
> >
> > This is a draft, to reflect on-going work in this area. It's intended
> > to be short and consumable. Suggestions welcome. I include the
> > synopsis below for better visibility and list search.
> >
> > https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
> >
> > ---
> >
> > Synopsis:
> >
> > The Fedora Workstation working group recognizes hibernation can be
> > useful, but due to impediments it's currently not practical to support
> > it. This is a recognition of the current state of affairs, but the
> > working group wishes hibernation could be relied upon, and thinks
> > there is a viable approach for limited support of hibernation in the
> > future. We encourage interested parties to pursue the needed
> > improvements. In the meantime, given that hibernation isn't currently
> > viable, the workstation WG decides that technical decisions will not
> > be constrained by it. Decisions about Workstation's 'out of the box'
> > configuration might conflict with the requirements of hibernation.
> > There are desired enhancements to performance and security that are
> > hindered by the status quo. The working group will re-evaluate when
> > the significant impediments have been adequately addressed.
> >
> > We will support an install time means of enabling hibernation retained
> > via Custom partitioning. If the user chooses to create a swap
> > partition, the installer will include a resume=UUID kernel parameter
> > hint so that the kernel can find the hibernation image.
> 
> I'm sorry, but this makes absolutely no sense. You can test hibernation right
> now, and it will work. When you boot back up, it'll have everything just as
> you left it. What systems is it broken on, those with Secure Boot? Is there
> something in GNOME that has changed in the past few releases which broke
> it?
> 
> I've just taken a Lenovo T500, installed GNOME Workstation and gone into
> hibernation. It took about 30 seconds to boot back in, but I was right where I
> left off. What exactly is broken, and for what portion of users?
> 
I can vouch that hibernate doesn't work on a bunch of platforms (including
the three that are part of the Lenovo+Fedora release). This is with secure 
boot disabled, big enough swap etc. On my X1C7 the device just shuts down 
and then it's as if you power cycled it when you power on again.

I started poking at it a bit (we even have a RH bug somewhere) but in the 
end have gone with "hibernate isn't supported" as the way forward.

Happy to help with the exercise if there are any pointers or data needed, 
guineau pig for testing etc. I didn't make much progress the last time I 
looked at it  I haven't seen much customer demand for it to be 
honest - but I appreciate the reasons why some would like it.

Mark
___
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: Supporting hibernation in Workstation ed., draft 1

[Chris Murphy]

On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr  wrote:
>
> I'm sorry, but this makes absolutely no sense.

Disliking the story is not the same thing as it not making sense.
There isn't much I can do about the former, but if you have a specific
area where there is a lack of clarity, I'll try to clear it up.


>You can test hibernation right
> now, and it will work. When you boot back up, it'll have everything just as
> you left it. What systems is it broken on, those with Secure Boot?

Not broken, disabled. That's the policy both upstream and in Fedora.

>Is there
> something in GNOME that has changed in the past few releases which broke it?

No.

> I've just taken a Lenovo T500, installed GNOME Workstation and gone into
> hibernation. It took about 30 seconds to boot back in, but I was right where I
> left off. What exactly is broken, and for what portion of users?

I don't know  the Lenovo T500 firmware setup defaults. If it conforms
to Microsoft Windows (8 or later) hardware certification
specifications, then UEFI Secure Boot is enabled by default. And it
mean you changed the defaults to get the results you're experiencing,
thereby disabling a  significant feature the Fedora invested
significant resources to explicitly support.


-- 
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: Fwd: Re: late generation of assemble code

[Colin Walters]

On Fri, May 29, 2020, at 8:01 PM, John M. Harris Jr wrote:

> WebAssembly is just in web browsers. It's not for normal software you'd 
> install with your package manager. Unless I'm missing something?

You are indeed missing

https://webassembly.org/docs/non-web/
https://wasi.dev/

More random links, and I'm sure others have better ones:

https://github.com/enarx/enarx/wiki/WebAssembly-(Wasm)
https://deislabs.io/posts/introducing-krustlet/
https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/
https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html
https://hacks.mozilla.org/2019/08/webassembly-interface-types/
___
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: Supporting hibernation in Workstation ed., draft 1

[John M. Harris Jr]

On Friday, May 29, 2020 3:58:26 PM MST Chris Murphy wrote:
> Hi,
> 
> Fedora Workstation working group has been investigating the working
> state of hibernation (suspend to disk) for about four months, and has
> produced a draft status report on the findings so far. Present status,
> impediments to support, and importantly, the specifics of how to
> address those impediments, are described.
> 
> This is a draft, to reflect on-going work in this area. It's intended
> to be short and consumable. Suggestions welcome. I include the
> synopsis below for better visibility and list search.
> 
> https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
> 
> ---
> 
> Synopsis:
> 
> The Fedora Workstation working group recognizes hibernation can be
> useful, but due to impediments it's currently not practical to support
> it. This is a recognition of the current state of affairs, but the
> working group wishes hibernation could be relied upon, and thinks
> there is a viable approach for limited support of hibernation in the
> future. We encourage interested parties to pursue the needed
> improvements. In the meantime, given that hibernation isn't currently
> viable, the workstation WG decides that technical decisions will not
> be constrained by it. Decisions about Workstation's 'out of the box'
> configuration might conflict with the requirements of hibernation.
> There are desired enhancements to performance and security that are
> hindered by the status quo. The working group will re-evaluate when
> the significant impediments have been adequately addressed.
> 
> We will support an install time means of enabling hibernation retained
> via Custom partitioning. If the user chooses to create a swap
> partition, the installer will include a resume=UUID kernel parameter
> hint so that the kernel can find the hibernation image.

I'm sorry, but this makes absolutely no sense. You can test hibernation right 
now, and it will work. When you boot back up, it'll have everything just as 
you left it. What systems is it broken on, those with Secure Boot? Is there 
something in GNOME that has changed in the past few releases which broke it?

I've just taken a Lenovo T500, installed GNOME Workstation and gone into 
hibernation. It took about 30 seconds to boot back in, but I was right where I 
left off. What exactly is broken, and for what portion of users?

-- 
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: Fwd: Re: late generation of assemble code

[John M. Harris Jr]

On Friday, May 29, 2020 1:56:16 PM MST Colin Walters wrote:
> > Perhaps in Silverblue or other systems  not designed to be a general
> > purpose operating system?
> 
> What, where did you get that?  Silverblue is general purpose.

Well, Silverblue is mostly GNOME. It's not meant for servers, etc.
 
> Anyways, my 2c on this topic: Once WebAssembly supports threads (it's
> coming) there's going to be a lot of interesting discussion about
> potentially using it in places where we compile native code in the
> operating system and applications today.
 
Err, what does WebAssembly have to do with real programs?

> IOW, it doesn't make sense to invest much in LLVM IR versus WebAssembly.

WebAssembly is just in web browsers. It's not for normal software you'd 
install with your package manager. Unless I'm missing something?

-- 
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: Packages that failed to build with Python 3.9

[Adam Williamson]

On Fri, 2020-05-29 at 21:59 +0200, Miro Hrončok wrote:
> Hello.
> 
> As you might already know, we have recently merged in the Python 3.9 side 
> tag, 
> despite several builds have not succeeded. We always aim for some compromise 
> between having the side tag open for too long and having too many failures.
> 
> The packages, when not rebuilt, are not installable in rawhide, hence fixing 
> them should be our top priority. If you need help with Python related issues, 
> we 
> (the Python Maintenance team at Red Hat) are happy to help. Unfortunately, 
> several packages fail to build for Python-unrelated reasons.
> 
> Some of the actual build failures already have a bugzilla open from our copr 
> rebuilds. Others don't have it yet because the error only manifested on some 
> architecture other than x86_64. I'll get back to this next week and open the 
> remaining bugzillas.
> 
> Most of the packages only fail to build because their dependencies were not 
> yet 
> rebuilt. Chances are, you already got an automated bugzilla from Igor, that 
> your 
> package fails to install. It would be really helpful if you could find the 
> missing dependency and mark the bugzilla for your package dependent on the 
> bugzilla for the missing dep. I slowly progress to do that as well, but your 
> help is crucial here.
> 
> Let me know if you have questions.
> 
> Here is the list:
> 
> Maintainers by package:
> 
> bugzilla2fedmsg  abompard
> calibre  chkr heliocastro kevin nushio zbyszek
> python-apsw  cicku dfateyev maci
> python-stompest  abompard

I fixed apsw and rebuilt calibre, which needed it. bugzilla2fedmsg
needs stompest, but stompest build (which you kicked off) seems to
actually be hanging during the test phase...we might need to tweak the
pytest args in the %check phase to find out why, I guess, or poke
around in mock (if it reproduces in a local mock).
-- 
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

Supporting hibernation in Workstation ed., draft 1

[Chris Murphy]

Hi,

Fedora Workstation working group has been investigating the working
state of hibernation (suspend to disk) for about four months, and has
produced a draft status report on the findings so far. Present status,
impediments to support, and importantly, the specifics of how to
address those impediments, are described.

This is a draft, to reflect on-going work in this area. It's intended
to be short and consumable. Suggestions welcome. I include the
synopsis below for better visibility and list search.

https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md

---

Synopsis:

The Fedora Workstation working group recognizes hibernation can be
useful, but due to impediments it's currently not practical to support
it. This is a recognition of the current state of affairs, but the
working group wishes hibernation could be relied upon, and thinks
there is a viable approach for limited support of hibernation in the
future. We encourage interested parties to pursue the needed
improvements. In the meantime, given that hibernation isn't currently
viable, the workstation WG decides that technical decisions will not
be constrained by it. Decisions about Workstation's 'out of the box'
configuration might conflict with the requirements of hibernation.
There are desired enhancements to performance and security that are
hindered by the status quo. The working group will re-evaluate when
the significant impediments have been adequately addressed.

We will support an install time means of enabling hibernation retained
via Custom partitioning. If the user chooses to create a swap
partition, the installer will include a resume=UUID kernel parameter
hint so that the kernel can find the hibernation image.


-- 
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

On 30. 05. 20 0:08, Orion Poplawski wrote:

On 5/29/20 8:17 AM, Miro Hrončok wrote:

On 22. 05. 20 3:06, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a coordinated rebuild 
in a side tag.


 https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.


The side tag has been merged. Thank you all for your patience.



Thank you Miro for all the hard work.


You are welcome. Thanks for your help with vtk an other packages you maintain, I 
know you don't have that much time for Fedora nowadays.


--
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: Packages that failed to build with Python 3.9

[Richard W.M. Jones]

On Fri, May 29, 2020 at 09:59:27PM +0200, Miro Hrončok wrote:
> coccinelle   rjones

This one has a bug and an upstream fix already, I "just" have to apply it:

https://bugzilla.redhat.com/show_bug.cgi?id=1791765#c10

The only possible problem is it seems to be bundling a Python library
which we didn't realise, so I need to unbundle that and make sure the
Python library is fixed in Fedora.

Anyway, will look into this soon.

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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Orion Poplawski]

On 5/29/20 8:17 AM, Miro Hrončok wrote:

On 22. 05. 20 3:06, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a coordinated 
rebuild in a side tag.


 https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your 
package, please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.


The side tag has been merged. Thank you all for your patience.



Thank you Miro for all the hard work.

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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: Packages that failed to build with Python 3.9

[Miro Hrončok]

On 29. 05. 20 22:38, Gwyn Ciesla via devel wrote:


‐‐‐ Original Message ‐‐‐
On Friday, May 29, 2020 2:59 PM, Miro Hrončok  wrote:


Hello.

As you might already know, we have recently merged in the Python 3.9 side tag,
despite several builds have not succeeded. We always aim for some compromise
between having the side tag open for too long and having too many failures.


When will python3 in the rawhide buildroot be 3.9?


It is.

Note that the component name is python3.9, but the binary package is still 
python3. The python3 component is retired.


--
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: Fwd: Re: late generation of assemble code

[Colin Walters]

> Perhaps in Silverblue or other systems  not designed to be a general purpose 
> operating system?

What, where did you get that?  Silverblue is general purpose.

Anyways, my 2c on this topic: Once WebAssembly supports threads (it's coming) 
there's going to be a lot of interesting discussion about potentially using it 
in places where we compile native code in the operating system and applications 
today.

IOW, it doesn't make sense to invest much in LLVM IR versus WebAssembly.
___
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 1841267] please build perl-Clipboard for epel8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-64d8621ef0 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-64d8621ef0


-- 
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 1841269] please build perl-Term-ShellUI for epel8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-690117dfc0 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-690117dfc0


-- 
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: Packages that failed to build with Python 3.9

[Gwyn Ciesla via devel]

‐‐‐ Original Message ‐‐‐
On Friday, May 29, 2020 2:59 PM, Miro Hrončok  wrote:

> Hello.
> 

> As you might already know, we have recently merged in the Python 3.9 side tag,
> despite several builds have not succeeded. We always aim for some compromise
> between having the side tag open for too long and having too many failures.
>

When will python3 in the rawhide buildroot be 3.9?

-- 

Gwyn Ciesla
she/her/hers
 

in your fear, seek only peace 

in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.
 

> The packages, when not rebuilt, are not installable in rawhide, hence fixing
> them should be our top priority. If you need help with Python related issues, 
> we
> (the Python Maintenance team at Red Hat) are happy to help. Unfortunately,
> several packages fail to build for Python-unrelated reasons.
> 

> Some of the actual build failures already have a bugzilla open from our copr
> rebuilds. Others don't have it yet because the error only manifested on some
> architecture other than x86_64. I'll get back to this next week and open the
> remaining bugzillas.
> 

> Most of the packages only fail to build because their dependencies were not 
> yet
> rebuilt. Chances are, you already got an automated bugzilla from Igor, that 
> your
> package fails to install. It would be really helpful if you could find the
> missing dependency and mark the bugzilla for your package dependent on the
> bugzilla for the missing dep. I slowly progress to do that as well, but your
> help is crucial here.
> 

> Let me know if you have questions.
> 

> Here is the list:
> 

> Maintainers by package:
> 5minute jhutar pmoravco
> Mayavi chedi orion
> TurboGears2 cverna ondrejj
> Zim cheeselee ohaessler
> abiword herrold huzaifas uwog
> airinv denisarnaud
> airrac denisarnaud
> airtsp denisarnaud
> ansible kevin toshio wzzrd
> ansible-inventory-grapher pnemade
> ansible-lint pnemade
> ansible-review dcallagh ttrinks
> ara dmsimard
> blender design-sw hobbes1069 ignatenkobrain kwizart luya roma
> s4504kr slaanesh
> bugzilla2fedmsg abompard
> calibre chkr heliocastro kevin nushio zbyszek
> cantor jreznik rdieter than
> cinch greghellings
> cjdns sdgathman
> coccinelle rjones
> commissaire-client mbarnes smilner
> coreboot-utils lkundrak peter
> cryptlib senderek
> csound pbrobinson sdz
> cura churchyard gferon
> diffoscope halfie zbyszek
> distro-info suraia
> enjarify zbyszek
> fonttools pnemade tagoh
> freecad hobbes1069 jkastner zultron
> gdeploy ramkrsna sac
> gfal2-util adev andreamanzi gbitzes
> gmsh hobbes1069 ignatenkobrain jkastner smani
> gpaw marcindulak
> home-assistant-cli fab
> imgbased dougsland fabiand sbonazzo yuvalturg
> ipsilon ngompa puiterwijk simo
> kdevelop-python dvratil jgrulich minh
> komikku atim lyessaadi
> lazygal rathann
> libcec pbrobinson
> libfreenect jkastner kwizart rmattes
> libtaskotron mkrizek
> libuser herczy jhrozek mitr
> lilv bsjones nphilipp tartina
> luxcorerender besser82 kwizart luya
> m2crypto mitr ngompa
> mailman3 abompard
> micropipenv lbalhar
> mirrormanager2 adrian
> mlt martinkg sergiomb
> mnemosyne itamarjp jpopelka rathann
> module-build-service cqi jkaluza mikem mprahl qwan ralph vmaljulin
> mom aglitke msivak sbonazzo
> moose zbyszek
> mu churchyard kushal
> needrestart duck
> notcurses nickblack
> nototools mfabian pwu
> ocrmypdf qulogic
> openslide-python bgilbert
> osc hguemar msuchy ngompa
> paraview deji orion sagitter
> pcp agerstmayr lberk mgoodwin nathans
> pcs cfeist idevat mlisik omular tojeline
> petsc4py sagitter
> player kwizart rmattes timn ttorling
> pre-commit atim chedi churchyard major
> py3status gchamoul kubo
> pydeps lbazan
> pyee pbrobinson
> pyflakes mrunge sbonazzo
> pygrib jdekloe
> pymol sagitter sergiomb
> pyosmium tomh
> pyproj jdekloe
> python-AppTools chedi orion
> python-CacheControl decathorpe
> python-IPy kevin
> python-SALib ankursinha
> python-Traits ignatenkobrain orion
> python-aioresponses gsauthof
> python-ansible-runner radez
> python-anyio carlwgeorge fab
> python-aodhclient apevec
> python-apsw cicku dfateyev maci
> python-asteval fab
> python-astral fab
> python-astroML lupinix
> python-astroscrappy lupinix
> python-asttokens zbyszek
> python-astunparse churchyard
> python-asynctest gsauthof
> python-azure-sdk melmorabity
> python-azure-storage melmorabity
> python-barbicanclient chandankumar jruzicka
> python-basemap jspaleta limb
> python-beniget churchyard
> python-black cheimes churchyard
> python-capturer cottsay
> python-cartopy qulogic
> python-ccdproc lupinix
> python-chameleon lmacken ralph tdabasin
> python-chaospy lbazan
> python-cheroot ignatenkobrain jcaratzas radez
> python-cherrypy ignatenkobrain jcaratzas mrunge radez
> python-cocotb tc01
> python-coloredlogs cottsay
> python-compreffor athoscr
> python-congressclient amoralej
> python-cram ktdreyer
> python-cu2qu athoscr
> python-debianbts huzaifas
> python-descartes qulogic
> 

Re: Packages that failed to build with Python 3.9

[Richard Shaw]

I'm already working on updating freecad to work with VTK 9.0 and
hopefully nothing falls apart with Python 3.9 while I'm at it.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Drop mod_php

[John M. Harris Jr]

On Friday, May 29, 2020 1:24:30 AM MST Igor Raits wrote:
> On Fri, 2020-05-29 at 01:00 -0700, John M. Harris Jr wrote:
> 
> > On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
> > 
> > > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
> > >
> > > > Please do not drop mod_php. It is NOT the case that "php-fpm is
> > > > already
> > > > used  but most users of httpd and nginx without any issue."
> > >
> > > php-fpm is the default configuration for httpd and nginx for few
> > > versions
> > >
> > > nginx ONLY uses php-fpm
> > >
> > > mod_php is httpd only and prefork mode only
> > > so without threaded MPM and without http2 support
> > >
> > > Please describe issues, I don't have any bug report about this.
> > >
> > > Remi
> >
> > Yes, nginx only uses php-fpm. But that has nothing to do with
> > mod_php.
> >
> > The default doesn't matter, there's absolutely no reason to take away
> > the
> > sysadmin's choice here. There are at least 40 servers I personally
> > am
> > responsible for where I see no reason to move from mod_php to php-
> > fpm, for
> > example. If you don't want to maintain it, I'd be happy to do so.
> > Many third
> > party packages expect mod_php, and nearly all documentation for
> > configuring
> > httpd for Fedora, CentOS and RHEL goes through the use of mod_php.
> > There is
> > just no reason to break this. People who want php-fpm will stick with
> > it, and
> > others will continue to use mod_php as we have for the last decade+.
> > Many
> > servers do not need http2, or other new features. Many of us have
> > something
> > that works, and we'd like to keep it working.
> 
> That's what CentOS / RHEL is for.

Are you saying that you believe Fedora is not suitable for long-term use? I 
really don't know why that would be, other than yanking out packages while 
they still work. However, this will have an affect on CentOS / RHEL as well, 
if it's removed from Fedora, it'll likely be removed there upon the next 
release. With that in mind, that's yet another reason this package should not 
be removed from Fedora. It'll break configs of the hundreds/thousands of users 
of Fedora's downstream projects, as well as a few hundred Fedora users.

This is a change that will seriously break a lot of peoples' config during 
their next system-upgrade, absolutely needlessly. That it's not the default 
already negates any perceived security issues.

-- 
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: Fwd: Re: late generation of assemble code

[John M. Harris Jr]

On Friday, May 29, 2020 4:02:40 AM MST Paul Dufresne via devel wrote:
> had forgotten to reply also to the list... doing it now:
> 
> [cut the part where it was suggested to make package that contains LLVM 
> Intermediate Representation bitcode rather than CPU specific assembler]
> 
> 
> On 2020-05-29 1:01 a.m., John M. Harris Jr wrote:
> 
> > Paul,
> > What benefit do you see in the overhead of LLVM IR, compared to standard
> > packages?
> 
> 
> John,
> 
> Where do you see overhead in the distribution of LLVM IR?

See below responses.

> Advantages:
> 
> * more space on the hard disks of the servers, because they contains 
> repositories only for LLVM IR packages rather than one by supported 
> architectures

This may be a valid point, but I'm not sure it's really all that important. 
I'm currently mirroring 3 different arches of the Fedora repos, and the total 
disk space is 495G. That's not a lot of storage space these days, at least not 
for servers. Additionally, there are a number of packages that cannot be LLVM 
IR, which are needed to support running LLVM IR. Please also consider how 
initramfs would be handled. Statically compiled software or LLVM IR and the 
supporting software?

> * less use of the CPU time of the servers because they don't optimize 
> code for specific CPUs

Not handling this on the build servers means doing it on the end system, every 
time the program is run.

> * very reduced cost for supporting more architectures, as code is 
> client-side generated

Does LLVM IR have a way of handling arch-specific code?

> * faster code on clients with recent CPUs, because code is optimized for 
> them, and was not in the old way of doing because you had to distribute 
> for a common base CPU

How does LLVM IR accomplish this? Would it be slower on older CPUs, or does it 
specifically compile for the host CPU's micro-arch?

> * CPU specific code generation and optimizations can be done on idle 
> time of the clients... there is not much idle time of the servers

If it's going to be done on idle time of client systems, this is definitely 
not going to work in Fedora in general. Perhaps in Silverblue or other systems 
not designed to be a general purpose operating system? It actually might even 
work in Fedora Workstation, but then you'd have to separate Workstation from 
the base distro, assuming GNOME doesn't eat CPU idle time.

-- 
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: Self Introduction: Sam Feifer

[Leigh Griffin]

Welcome Sam, hope to see you around!

On Fri, May 29, 2020, 20:30 Samuel Jacob Feifer 
wrote:

> Hi everyone. I am currently a second year computer science student at
> Vanderbilt and would love to garner some experience this summer working
> with fedora. As my career is quite young, I hope to not only become a more
> confident programmer, but also familiarize myself with how professional
> programers communicate and interact while working on projects. So far, I've
> learned java and python and while my main goal is to contribute to
> programs, I would still appreciate just tagging along to a project and
> seeing the steps made to finish it. If you'd like to add me to an irc chat
> my username and nick are sfeifer.
>
> Thanks
> --Sam
> ___
> 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

Packages that failed to build with Python 3.9

[Miro Hrončok]

Hello.

As you might already know, we have recently merged in the Python 3.9 side tag, 
despite several builds have not succeeded. We always aim for some compromise 
between having the side tag open for too long and having too many failures.


The packages, when not rebuilt, are not installable in rawhide, hence fixing 
them should be our top priority. If you need help with Python related issues, we 
(the Python Maintenance team at Red Hat) are happy to help. Unfortunately, 
several packages fail to build for Python-unrelated reasons.


Some of the actual build failures already have a bugzilla open from our copr 
rebuilds. Others don't have it yet because the error only manifested on some 
architecture other than x86_64. I'll get back to this next week and open the 
remaining bugzillas.


Most of the packages only fail to build because their dependencies were not yet 
rebuilt. Chances are, you already got an automated bugzilla from Igor, that your 
package fails to install. It would be really helpful if you could find the 
missing dependency and mark the bugzilla for your package dependent on the 
bugzilla for the missing dep. I slowly progress to do that as well, but your 
help is crucial here.


Let me know if you have questions.

Here is the list:

Maintainers by package:
5minute  jhutar pmoravco
Mayavi   chedi orion
TurboGears2  cverna ondrejj
Zim  cheeselee ohaessler
abiword  herrold huzaifas uwog
airinv   denisarnaud
airrac   denisarnaud
airtsp   denisarnaud
ansible  kevin toshio wzzrd
ansible-inventory-grapher pnemade
ansible-lint pnemade
ansible-review   dcallagh ttrinks
ara  dmsimard
blender  design-sw hobbes1069 ignatenkobrain kwizart luya roma 
s4504kr slaanesh

bugzilla2fedmsg  abompard
calibre  chkr heliocastro kevin nushio zbyszek
cantor   jreznik rdieter than
cinchgreghellings
cjdnssdgathman
coccinelle   rjones
commissaire-client   mbarnes smilner
coreboot-utils   lkundrak peter
cryptlib senderek
csound   pbrobinson sdz
cura churchyard gferon
diffoscope   halfie zbyszek
distro-info  suraia
enjarify zbyszek
fonttoolspnemade tagoh
freecad  hobbes1069 jkastner zultron
gdeploy  ramkrsna sac
gfal2-util   adev andreamanzi gbitzes
gmsh hobbes1069 ignatenkobrain jkastner smani
gpaw marcindulak
home-assistant-cli   fab
imgbased dougsland fabiand sbonazzo yuvalturg
ipsilon  ngompa puiterwijk simo
kdevelop-python  dvratil jgrulich minh
komikku  atim lyessaadi
lazygal  rathann
libcec   pbrobinson
libfreenect  jkastner kwizart rmattes
libtaskotron mkrizek
libuser  herczy jhrozek mitr
lilv bsjones nphilipp tartina
luxcorerenderbesser82 kwizart luya
m2crypto mitr ngompa
mailman3 abompard
micropipenv  lbalhar
mirrormanager2   adrian
mlt  martinkg sergiomb
mnemosyneitamarjp jpopelka rathann
module-build-service cqi jkaluza mikem mprahl qwan ralph vmaljulin
mom  aglitke msivak sbonazzo
moosezbyszek
mu   churchyard kushal
needrestart  duck
notcursesnickblack
nototoolsmfabian pwu
ocrmypdf qulogic
openslide-python bgilbert
osc  hguemar msuchy ngompa
paraview deji orion sagitter
pcp  agerstmayr lberk mgoodwin nathans
pcs  cfeist idevat mlisik omular tojeline
petsc4py sagitter
player   kwizart rmattes timn ttorling
pre-commit   atim chedi churchyard major
py3statusgchamoul kubo
pydeps   lbazan
pyee pbrobinson
pyflakes mrunge sbonazzo
pygrib   jdekloe
pymolsagitter sergiomb
pyosmium tomh
pyproj   jdekloe
python-AppTools  chedi orion
python-CacheControl  decathorpe
python-IPy   kevin
python-SALib ankursinha
python-Traitsignatenkobrain orion
python-aioresponses  gsauthof
python-ansible-runner radez
python-anyio carlwgeorge fab
python-aodhclientapevec
python-apsw  cicku dfateyev maci
python-asteval   fab
python-astralfab
python-astroML   lupinix
python-astroscrappy  lupinix
python-asttokens zbyszek
python-astunparsechurchyard
python-asynctest gsauthof
python-azure-sdk melmorabity
python-azure-storage melmorabity
python-barbicanclient chandankumar jruzicka
python-basemap   jspaleta limb
python-beniget   churchyard
python-black cheimes churchyard
python-capturer  cottsay
python-cartopy   qulogic

Re: fwupd / LVFS RFE: classifying updates?

[Michel Alexandre Salim]

On 5/22/20 11:42 AM, Richard Hughes wrote:

On Fri, May 22, 2020 at 5:58 PM Michel Alexandre Salim
 wrote:

If it's reasonable to have such toggles for fwupdmgr, we're happy to> send a 
pull request for it.


Sure, this seems like a sane request. We already have "--filter" so
something like --filter=urgency:high would fit nicely there. Open up
an issue on the upstream fwupd issue tracker and we'll discuss there.


https://github.com/fwupd/fwupd/issues/2152 -- sorry for the delay!

Best regards,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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 1841910] New: perl-Dist-Zilla-6.015 is available

[bugzilla]

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

Bug ID: 1841910
   Summary: perl-Dist-Zilla-6.015 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dist-Zilla
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
psab...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.015
Current version/release in rawhide: 6.014-1.fc33
URL: http://search.cpan.org/dist/Dist-Zilla/

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


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

Self Introduction: Sam Feifer

[Samuel Jacob Feifer]

Hi everyone. I am currently a second year computer science student at 
Vanderbilt and would love to garner some experience this summer working with 
fedora. As my career is quite young, I hope to not only become a more confident 
programmer, but also familiarize myself with how professional programers 
communicate and interact while working on projects. So far, I've learned java 
and python and while my main goal is to contribute to programs, I would still 
appreciate just tagging along to a project and seeing the steps made to finish 
it. If you'd like to add me to an irc chat my username and nick are sfeifer.

Thanks
--Sam
___
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

[389-devel] please review: PR 51127 - UI - improve instance creation form validation

[Mark Reynolds]

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

--

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

Re: PSA: pytest 5 now finally available in rawhide

[Miro Hrončok]

On 29. 05. 20 17:57, Miro Hrončok wrote:

Hello,

the pytest package (python3-pytest) has been updated to 5.4.2.

In case it gives you trouble, you can pin an older version:

   BuildRrequires: %{py3_dist pytest} < 5

Or:

   BuildRrequires: python3dist(pytest) < 5

That will give you the python3-pytest4 package (4.6.10 now), not parallely 
installable with python3-pytest.


Note that the python3-pytest4 package is deprecated, but no removal date has 
been set. Likely, it will get orphaned or retired when no important packages 
need it.


The pytest 4.6.x series is still being occasionally released, but:

https://docs.pytest.org/en/latest/py27-py34-deprecation.html#maintenance-of-4-6-x-versions 



"From now on, the core team will no longer actively backport patches, but the 
4.6.x branch will continue to exist so the community itself can contribute 
patches."


Side note: The Fedora 31/32 python3-pytest package does not provide 
python3-pytest4, hence I recommend not to BuildRequire python3-pytest4 directly 
by name, but using python3dist(pytest) or %py3_dist as in the examples above.


For this very reason, the following packages might want to switch to not require 
python3-ptest by name:


$ repoquery --repo=rawhide --whatrequires python3-pytest --exact
copr-keygen-0:1.77-1.fc32.noarch
hatch-0:0.23.0-2.fc32.noarch
python3-astropy-0:4.0.1.post1-1.fc33.x86_64
python3-conu-pytest-0:0.7.1-8.fc32.noarch
python3-django-pytest-0:0.2.0-24.fc32.noarch
python3-gabbi-0:1.49.0-1.fc32.noarch
python3-ipatests-0:4.8.6-1.fc33.noarch
python3-ipyparallel-tests-0:6.3.0-1.fc33.noarch
python3-ipython-tests-0:7.14.0-1.fc33.noarch
python3-lib389-0:1.4.4.2-1.fc33.1.noarch
python3-metakernel-tests-0:0.24.4-1.fc33.noarch
python3-pyfakefs-0:3.5.8-5.fc32.noarch
python3-pytest-arraydiff-0:0.3-5.fc32.noarch
python3-pytest-astropy-0:0.5.0-4.fc32.noarch
python3-pytest-asyncio-0:0.10.0-5.fc32.noarch
python3-pytest-beakerlib-0:0.7.1-12.fc32.noarch
python3-pytest-benchmark-0:3.2.3-1.fc33.noarch
python3-pytest-cache-0:1.0-21.fc33.noarch
python3-pytest-capturelog-0:0.7-19.fc32.noarch
python3-pytest-doctestplus-0:0.3.0-5.fc32.noarch
python3-pytest-faulthandler-0:1.6.0-5.fc32.noarch
python3-pytest-forked-0:1.1.1-2.fc32.noarch
python3-pytest-httpbin-0:0.3.0-11.fc32.noarch
python3-pytest-mock-0:1.10.4-7.fc32.noarch
python3-pytest-openfiles-0:0.3.2-5.fc32.noarch
python3-pytest-relaxed-0:1.1.5-7.fc32.noarch
python3-pytest-remotedata-0:0.3.1-5.fc32.noarch
python3-pytest-runner-0:4.0-9.fc32.noarch
python3-pytest-sourceorder-0:0.5-17.fc32.noarch
python3-pytest-spec-0:2.0.0-2.fc32.noarch
python3-pytest-testmon-0:0.9.19-2.fc32.noarch
python3-pytest-timeout-0:1.3.4-2.fc32.noarch
python3-pytest-vcr-0:1.0.2-5.fc32.noarch
python3-pytest-virtualenv-0:1.7.0-6.fc32.noarch
python3-pytest-watch-0:4.2.0-5.fc32.noarch
python3-pytest-xdist-0:1.32.0-1.fc33.noarch
python3-qcelemental-0:0.12.0-3.fc32.noarch
python3-rustcfg-tests-0:0.0.2-6.fc32.noarch
python3-tinyrpc-tests-0:1.0.3-2.fc32.noarch

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Petr Viktorin]

On 2020-05-29 16:39, Miro Hrončok wrote:

On 29. 05. 20 16:25, Richard Shaw wrote:
On Fri, May 29, 2020 at 9:18 AM Miro Hrončok > wrote:



    The side tag has been merged. Thank you all for your patience.


Woohoo! So now Python can be rebuilt with the fix for PySide2? :)


Technically blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1839826

But I am sure Petr is working on it.


It's progressing, though slower than I hoped due to other issues. I'll 
rebuild PySide and close the bug when done.

___
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: How to determine maintainer of a package en mass?

[Alessio]

On Fri, 2020-05-29 at 01:34 +0200, Fabio Valentini wrote:
> 
> This shows all the packages for which you are "owner" / "main admin":
> https://src.fedoraproject.org/dashboard/projects?acl=main+admin

There is also a way to get the packages for wich another user is the
owner?

Ciao,
A.
___
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: How to determine maintainer of a package en mass?

[Petr Viktorin]

On 2020-05-29 01:34, Fabio Valentini wrote:

On Fri, May 29, 2020 at 1:16 AM Richard Shaw  wrote:


Specifically, I would like a way to determine which packages I am the sole 
maintainer of or the main maintainer.

Long story short, I've been spending far too much time on packaging work and it's taking 
away from $LIFE, $DAYJOB, and other hobbies I used to enjoy. I need to offload the 
primary maintenance of some of them to "lighten the load" so to speak.

No worries, I'm not disappearing or anything and will continue to do what I can.


This shows all the packages for which you are "owner" / "main admin":
https://src.fedoraproject.org/dashboard/projects?acl=main+admin

This shows all packages for which you have "admin" access (whether
directly or via group membership):
https://src.fedoraproject.org/dashboard/projects?acl=admin

Do those two pages show the information you need?


There's also a JSON with all maintainers for all packages here: 
https://src.fedoraproject.org/extras/pagure_owner_alias.json

___
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: Many packages unnecessarily link to libpython

[Petr Viktorin]

On 2020-05-18 03:53, Honggang LI wrote:

On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:

rdma-coredledford honli jwilson


rdma-core pyverbs must be linked with libpython38. For example,

build]$ nm ./python/pyverbs/mem_alloc.cpython-38-x86_64-linux-gnu.so | grep -w 
U |  grep  PyInterpreterState_GetID
U PyInterpreterState_GetID

Python-3.8.3]$ nm -a ./build/debug/libpython3.8d.so | grep 
PyInterpreterState_GetID
000c6a82 T PyInterpreterState_GetID


This is exactly the case where the module should *not* be linked to 
/usr/lib64/libpython3.8.so.
mem_alloc.cpython-38-x86_64-linux-gnu.so is a Python module, so it is 
loaded from Python when imported. The import will link link it to the 
particular Python interpreter it's imported into, which could be using a 
different libpython3.8.so (such as the debug version).

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rawhide broken: crypto-policies

[Jerry James]

On Fri, May 29, 2020 at 10:25 AM Igor Raits
 wrote:
> This is fixed now.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1841851

Thank you for the quick response.
-- 
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: Rawhide broken: crypto-policies

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2020-05-29 at 10:08 -0600, Jerry James wrote:
> Trying to build a package just now failed
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531):
> 
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> Transaction test succeeded.
> Running transaction
> error: lua script failed: [string
> "%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19:
> attempt to call a nil value
> 
> Error in PREIN scriptlet in rpm package crypto-policies
> error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install
> failed

This is fixed now.

https://bugzilla.redhat.com/show_bug.cgi?id=1841851
> 
> -- 
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7RNzUACgkQEV1auJxc
Hh63xg/9EbBPd1jZ/0T8Dz3/te4VtBYFwV6Z/8WuRmnuINADIoFw18bd3VsFur7z
e1tyuEZUxHVpvg0WJA43ktJxYeG8cVQoyXeTdD4wIAW7DWIuFIE9IKSyGLpajxXQ
/TNlIjyR52zcUsltrbra64NB0+WP8I25HzjVbumzB4jWEl8/XIqFBja9Qaco1Z06
6odCLzdpuKVzJDqHXubhVI1ZnKX61tDPlDsGp/BH/+wb48/sos31dRAHoR22dhwl
uzlyBsbfvcvZrLr/RmBQtZCXHyXbrtI5S3aPMNX1GcQkG5UOc4WxZWHhJb09AA2B
Rs5PmU+O8MNk3t5VX3Ra6FhbsrG+tk+eRzZ2voxYBiWbFBNDbhmoGqAFgvxgNCRj
dfQc0V5rMUxpoM1KglNUAKDJuZP2lW3K3KvQyXchnaG/uwNPxneJxsmgavRFB0yC
2HAL2f16TQbfABGw8kFy9Vc1lghbTZu2cTgaVjwYLd0IOVqntzQ0iSpFK5P5D/8B
F+TBknkYwcfp2WotNLAAtd1dBkEy9Z6CWAHUKcMfUgdWt0FDvL3syJa4GQSe+/++
GgUcR8/SqX3Gszv8RnhYk2ziq3quEj8pcaUNEk+7Aia/8Xj60O6uou0zGBxU29EO
i1b4h98ftK2rmdet+OJTbBeikLmnRSyTghgLpWF6mmwED6SM5W0=
=OETP
-END 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: Rawhide broken: crypto-policies

[Miro Hrončok]

On 29. 05. 20 18:08, Jerry James wrote:

Trying to build a package just now failed
(https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531):

Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
error: lua script failed: [string
"%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19:
attempt to call a nil value

Error in PREIN scriptlet in rpm package crypto-policies
error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install failed


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

Mohan and Igor are untagging the build now.

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

Rawhide broken: crypto-policies

[Jerry James]

Trying to build a package just now failed
(https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531):

Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
error: lua script failed: [string
"%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19:
attempt to call a nil value

Error in PREIN scriptlet in rpm package crypto-policies
error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install failed

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

PSA: pytest 5 now finally available in rawhide

[Miro Hrončok]

Hello,

the pytest package (python3-pytest) has been updated to 5.4.2.

In case it gives you trouble, you can pin an older version:

  BuildRrequires: %{py3_dist pytest} < 5

Or:

  BuildRrequires: python3dist(pytest) < 5

That will give you the python3-pytest4 package (4.6.10 now), not parallely 
installable with python3-pytest.


Note that the python3-pytest4 package is deprecated, but no removal date has 
been set. Likely, it will get orphaned or retired when no important packages 
need it.


The pytest 4.6.x series is still being occasionally released, but:

https://docs.pytest.org/en/latest/py27-py34-deprecation.html#maintenance-of-4-6-x-versions

"From now on, the core team will no longer actively backport patches, but the 
4.6.x branch will continue to exist so the community itself can contribute patches."


Side note: The Fedora 31/32 python3-pytest package does not provide 
python3-pytest4, hence I recommend not to BuildRequire python3-pytest4 directly 
by name, but using python3dist(pytest) or %py3_dist as in the examples above.


--
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 34 System-Wide Change proposal: NSS CK_GCM_PARAMS change

[Robert Relyea]

Oops, this reply was supposed to be a "reply list" rather than a "reply".

I've incorporated most of your feedback into the Change page now.

Thanks.

bob

On 5/29/20 12:23 AM, Zbigniew Jędrzejewski-Szmek wrote:


On Thu, May 28, 2020 at 03:46:25PM -0400, Ben Cotton wrote:

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

== Summary ==
Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to
change the definition of CK_GCM_PARAMS in a source incompatible way.
Upstream made this change in NSS 3.52.

When I'm reading this description, it feels like it was written by
somebody deep in the subject, but Change pages need to be accessible
to a general audience, even people who don't program in C. They should
be able to get the gist without having to absorb all the details.
Thanks, If you don't program in C, the change has no affect on you. It's 
a source level incompatibility, not a binary. I'll add that to the 
description.


It'd help if this summary mentioned that CK_GCM_PARAMS is a struct
definition and that a new field was added (if I got that right) and that
end programs need to adjust by changing how they do [what?].
Yup, how to adjust is described below. I'm trying to keep the summary 
short.

== Owner ==
* Name: [[User:rrelyea| Bob Relyea]]
* Email: rrel...@redhat.com


== Detailed Description ==
PKCS #11 2.40 had a mismatch between the SPEC and the released header
file for CK_GCM_PARAMS. The latter is controlling. We created or
header based on the former. In PKCS #11 v3.0 the reconciled this, but
it left us with. The new (to NSS) definition has a new field ulIvBits,
which must be set correctly.
This part is very hard to grok. Is the capitalized "SPEC" an 
abbreviation?

One of the sentences ends mid-sentence. Also "must be set correctly"
by whom, how?

I need to fix some typos. "must be set correctly" is described below.



To solve this, the NSS 3.52 headers has both definitions:
CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3
is the new (to NSS) definition. CK_GCM_PARAMS takes on one or the
other based on the definition of NSS_PKCS11_2_0_COMPAT.

The current NSS builds in fedora have changes the sense of this
#define to NSS_PKCS11_3_0_STRICT to get the new behavior, and keep the
old behavior by default. NSS builds will automatically switch back to
the upstream default in Fedora 34. None of the changes below actually
requires setting the NSS_PKCS11_3_STRICT define, though doing so can
test that all but option 1 is functioning.

Applications can fix this the following ways:

option 1

  #define NSS_PKCS11_2_0_COMPAT 1

or compile with -DNSS_PKCS11_2_0_COMPAT

your app will compile and run using current and older versions of NSS,
but may break on newer tokens that use the new definition (same as the
previous behavior.

---

option 2

rename CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss

= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT).

Like option 2 it may break on newer tokens.

What does "rename" mean in this context? Based on the earlier text, I
thought CK_GCM_PARAMS was a structure...

It is. change your instances of CK_GCM_PARAMS to CK_GCM_PARAMS_V3

--

option 3

rename CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.

This will require nss >= 3.52 to compile and to run. Should run on all
run tokens.

-

option 4

Move to PK11_AEADOp  interface, which all requires nss >= 3.52 to
compile and run,  but it's less surprising and the dependency will be
picked up automatically because you are using a new for 3.52
interface.
--

Option 4 is the preferred solution. It takes advantage the the PKCS
#11 v3 interface for  AES_GCM while removing any PCKS #11 param
structure dependency in the application. It also handles backward
compatibility on older tokens and automatically detects which flavor
of data structure is supported. It also would help with applications
that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY.

== Benefit to Fedora ==
This change will keep fedora with the NSS upstream as well as make
Fedora compliant with the official OASIS PKCS #11 spec.

== Scope ==
* Proposal owners: NSS 3.52 has already had builds made with the
reverse sense. NSS will need to be rebuilt at the start of Fedora 34.

* Other developers:  Developers need to choose one of these options by
fedora 34 or their rebuilt packages will fail at runtime.

The text from above starts repeating here?

I guess I could say "see description".



option 1

  #define NSS_PKCS11_2_0_COMPAT 1

or compile with -DNSS_PKCS11_2_0_COMPAT

your app will compile and run using current and older versions of NSS,
but may break on newer tokens that use the new definition (same as the
previous behavior.

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a 
side tag.


     https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.


The side tag has been merged. Thank you all for your patience.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org

Re: F30 security update submitted for stable "marked obsolete" instead of being pushed

[Kevin Kofler]

Miro Hrončok wrote:
> AFAIK this was never the case, but I'm not sure. I remember in the past
> the updates just kinda stuck in limbo (being pushed to stable for
> eternity). At least now they are marked as obsolete.

I think there really ought to be a guarantee that everything queued before 
the deadline actually gets pushed in one last push, as opposed to saying 
"sorry, the last push was actually hours earlier than the official deadline, 
you're screwed forever because we will never do a push again for that 
release".

Kevin Kofler
___
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

nauty 2.7 rebuilds

[Jerry James]

I plan to update nauty from the 2.6 series to the 2.7 series soon.
The new version is *almost* backwards compatible with 2.6.  However,
one member of the optionstruct structure changed size (from 32 bits to
64 bits), so out of an abundance of caution I am going to rebuild all
consumers.  The packages to be rebuilt are:

coin-or-Cbc
coin-or-Couenne
gap-pkg-nautytracesinterface
giac
Macaulay2
normaliz
polymake

I have done successful mock builds of all except Macaulay2, which
appears to be suffering from a garbage collector issue.  I'm looking
at how to fix that.  Once I figure it out, I will start these builds,
with the goal of completing them before the datacenter move starts.
-- 
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

On 29. 05. 20 16:25, Richard Shaw wrote:
On Fri, May 29, 2020 at 9:18 AM Miro Hrončok > wrote:



The side tag has been merged. Thank you all for your patience.


Woohoo! So now Python can be rebuilt with the fix for PySide2? :)


Technically blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1839826

But I am sure Petr is working on it.

--
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Richard Shaw]

On Fri, May 29, 2020 at 9:18 AM Miro Hrončok  wrote:

>
> The side tag has been merged. Thank you all for your patience.
>

Woohoo! So now Python can be rebuilt with the fix for PySide2? :)

Thanks,
Richard
___
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 1841510] [RFE] EPEL-8 branch for perl-Crypt-Random-Seed

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-fb765aaeb7 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fb765aaeb7


-- 
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a 
side tag.


     https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.


The side tag has been merged. Thank you all for your patience.

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

[Bug 1841510] [RFE] EPEL-8 branch for perl-Crypt-Random-Seed

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Crypt-Random-Seed-0.03
   ||-16.el8
   ||perl-Crypt-Random-Seed-0.03
   ||-16.epel8.playground




-- 
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: python3-pyparsing: conflicting error

[Jonathan Wakely]

On 29/05/20 15:21 +0200, Fabio Valentini wrote:

On Fri, May 29, 2020 at 2:29 PM Jun Aruga  wrote:


This just happened on Fedora rawhide build now.

Could anyone fix it?

https://koji.fedoraproject.org/koji/taskinfo?taskID=45138807
https://kojipkgs.fedoraproject.org//work/tasks/8880/45138880/root.log

DEBUG util.py:600:  No matches found for the following disable plugin
patterns: local, spacewalk
DEBUG util.py:600:  Error:
DEBUG util.py:600:   Problem: package
systemtap-sdt-devel-4.3-0.20200212git91ffb97ad335.fc33.x86_64 requires
python3-pyparsing, but none of the providers can be installed
DEBUG util.py:600:- conflicting requests
DEBUG util.py:600:- nothing provides python(abi) = 3.9 needed by
python3-pyparsing-2.4.7-3.fc33.noarch
DEBUG util.py:602:  (try to add '--skip-broken' to skip uninstallable packages)


You seem to have submitted that build in an unfortunate time window
between python 3.9 landing in rawhide, not reading the loud [HEADS UP]
thread, and the rebuilt systemtap landing in rawhide.

It seems koji has now run a newRepo task and the dependencies are
fixed again, so you should be able to just resubmit the same build
again now, and it should work.


Please don't. systemtap also depends on Boost, which is also being
built in a side tag.

Please read the [HEADS UP] mails to this list, we send them for a
reason.

___
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: python3-pyparsing: conflicting error

[Fabio Valentini]

On Fri, May 29, 2020 at 2:29 PM Jun Aruga  wrote:
>
> This just happened on Fedora rawhide build now.
>
> Could anyone fix it?
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45138807
> https://kojipkgs.fedoraproject.org//work/tasks/8880/45138880/root.log
>
> DEBUG util.py:600:  No matches found for the following disable plugin
> patterns: local, spacewalk
> DEBUG util.py:600:  Error:
> DEBUG util.py:600:   Problem: package
> systemtap-sdt-devel-4.3-0.20200212git91ffb97ad335.fc33.x86_64 requires
> python3-pyparsing, but none of the providers can be installed
> DEBUG util.py:600:- conflicting requests
> DEBUG util.py:600:- nothing provides python(abi) = 3.9 needed by
> python3-pyparsing-2.4.7-3.fc33.noarch
> DEBUG util.py:602:  (try to add '--skip-broken' to skip uninstallable 
> packages)

You seem to have submitted that build in an unfortunate time window
between python 3.9 landing in rawhide, not reading the loud [HEADS UP]
thread, and the rebuilt systemtap landing in rawhide.

It seems koji has now run a newRepo task and the dependencies are
fixed again, so you should be able to just resubmit the same build
again now, and it should work.

Fabio

> --
> Jun | He - His - Him
> ___
> 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: python3-pyparsing: conflicting error

[Michael Schwendt]

On Fri, 29 May 2020 15:09:34 +0200, Jun Aruga wrote:

> I opened the issue ticket for systemtap.
> https://bugzilla.redhat.com/show_bug.cgi?id=1841558

Why would you do that?
It's "python3" (3.8) -> "python3.9" dependency breakage.
___
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: python3-pyparsing: conflicting error

[Scott Talbert]

On Fri, 29 May 2020, Jun Aruga wrote:


I opened the issue ticket for systemtap.
https://bugzilla.redhat.com/show_bug.cgi?id=1841558


I suspect this is probably because of the Python 3.9 rebuild being merged 
back into rawhide.  See the [HEADS UP] thread...

___
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: python3-pyparsing: conflicting error

[Jun Aruga]

I opened the issue ticket for systemtap.
https://bugzilla.redhat.com/show_bug.cgi?id=1841558

-- 
Jun | He - His - Him
___
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 1841308] remove hardcoded requirement for Crypt::Random

[bugzilla]

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



--- Comment #3 from Charles R. Anderson  ---
(In reply to Paul Howarth from comment #2)
> This looks like it would work but you seem to have changed the
> Bytes::Random::Secure version requirement from 0.09 to 0.29 for some reason?

0.29 is the latest on CPAN, but I didn't check what version we ship now:

https://metacpan.org/pod/Bytes::Random::Secure


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

python3-pyparsing: conflicting error

[Jun Aruga]

This just happened on Fedora rawhide build now.

Could anyone fix it?

https://koji.fedoraproject.org/koji/taskinfo?taskID=45138807
https://kojipkgs.fedoraproject.org//work/tasks/8880/45138880/root.log

DEBUG util.py:600:  No matches found for the following disable plugin
patterns: local, spacewalk
DEBUG util.py:600:  Error:
DEBUG util.py:600:   Problem: package
systemtap-sdt-devel-4.3-0.20200212git91ffb97ad335.fc33.x86_64 requires
python3-pyparsing, but none of the providers can be installed
DEBUG util.py:600:- conflicting requests
DEBUG util.py:600:- nothing provides python(abi) = 3.9 needed by
python3-pyparsing-2.4.7-3.fc33.noarch
DEBUG util.py:602:  (try to add '--skip-broken' to skip uninstallable packages)

-- 
Jun | He - His - Him
___
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 1841512] [RFE] EPEL-8 branch for perl-Statistics-Basic

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|dd...@cpan.org  |ppi...@redhat.com




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

perl-Statistics-Basic license corrected to "LGPLv2 and LGPLv2+"

[Petr Pisar]

I corrected perl-Statistics-Basic license from "LGPLv2+" to "LGPLv2 and 
LGPLv2+".

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

Fedora-Cloud-31-20200529.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (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

Rebuilt for OpenCV 4.3.0 in rawhide

[Nicolas Chauvet]

Hello there,

There is an update to opencv 4.3.0 in preparation for rawhide.
This will be handled in a side tag along with the rebuild of the all
dependencies.
(fedpkg build --target=f33-build-side-24026)

This was evaluated ahead,so it should lead to issue.
https://copr.fedorainfracloud.org/coprs/kwizart/opencv4/builds/
(failures are random issue on copr builders, should be all green on koji).

We will merge the side tag next week and once everything have been rebuilt.

Thanks

-- 
-

Nicolas (kwizart)
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

On 29. 05. 20 13:07, Jonathan Wakely wrote:

On 29/05/20 12:17 +0200, Miro Hrončok wrote:

On 29. 05. 20 11:49, Jonathan Wakely wrote:

On 29/05/20 09:34 +0200, Miro Hrončok wrote:

On 29. 05. 20 9:32, Felix Schwarz wrote:


Am 29.05.20 um 09:19 schrieb Miro Hrončok:

The side tag is being merged right now.


Thank you for all the work (also in advance with all the alpha/beta 
versions) :-)


Seems like quite a few Python packages were rebuilt in rawhide during your
mass rebuild. Did that happen in the past as well? (I don't remember it that
way but also I did not monitor previous python rebuilds closely).


In previous upgrades, we haven't checked and after we asked releng to merge 
the side tag, we just realized several packages were rebuilt (incl. a small 
boostrap loop once and anaconda the other time). Hence this time, I've been 
monitoring the situation. Less then 10 packages were bumped and built in 
rawhide during the rebuilds this time.


Could you send me the list of those packages, if you have it?


I've rebuilt them all again.


Are any of them in the list of packages that I need to rebuild anyway
for the boost1.73+python3.9 combo?


No.


OK, great, nothing extra for me to do then :-)


By the way, I accidentally rebuilt player in the f33-boost side tag,
because my makefile incorrectly listed it as a prerequisite of gazebo
and so automatically added it to my rebuilds (it *is* a prerequisite
of gazebo, but doesn't use boost so I didn't need to do it). I noticed
that your f33-python build of player didn't work, so I'll add that to
the list of ones to rebuild in my tag after f33-python finishes
merging (apparently they're still being signed).


The signing is taking ages :/


Yes, but python3-3.8.3-1.fc33 is done, so I'll rebuild boost in my
side tag and resume my rebuilds there.


This was a Python 3.9 rebuild, not 3.8. We need to wait for:

  python3.9-3.9.0~b1-3.fc33

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

[Bug 1841510] [RFE] EPEL-8 branch for perl-Crypt-Random-Seed

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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



--- Comment #1 from Petr Pisar  ---
https://pagure.io/releng/fedora-scm-requests/issue/25364
https://pagure.io/releng/fedora-scm-requests/issue/25365


-- 
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 1841308] remove hardcoded requirement for Crypt::Random

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||1802983





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1802983
[Bug 1802983] RFE - build kpcli for EPEL 8
-- 
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 1841262] please build for perl-Crypt-Random for epel8

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks|1802983 |





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1802983
[Bug 1802983] RFE - build kpcli for EPEL 8
-- 
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 1841523] New: perl-Net-Pcap for EPEL 8

[bugzilla]

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

Bug ID: 1841523
   Summary: perl-Net-Pcap for EPEL 8
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Net-Pcap
  Assignee: dd...@cpan.org
  Reporter: sa...@waytotheweb.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, iarn...@gmail.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org,
sindr...@fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Could you please add perl-Net-Pcap to EPEL 8.

v0.18 from cpan does not compile on for example CentOS v8 and requires a patch:

https://github.com/eserte/srezic-cpan-distroprefs/blob/master/Net-Pcap.yml#L18
https://www.cpan.org/modules/by-module/GD/SREZIC/patches/Net-Pcap-0.18-RT127685-RH1485429.patch

Regards,
Jonathan


-- 
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 1841510] [RFE] EPEL-8 branch for perl-Crypt-Random-Seed

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||1841514





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1841514
[Bug 1841514] [RFE] EPEL-8 branch for perl-Bytes-Random-Secure
-- 
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 1841308] remove hardcoded requirement for Crypt::Random

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Depends On||1841514





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1841514
[Bug 1841514] [RFE] EPEL-8 branch for perl-Bytes-Random-Secure
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Jonathan Wakely]

On 29/05/20 12:17 +0200, Miro Hrončok wrote:

On 29. 05. 20 11:49, Jonathan Wakely wrote:

On 29/05/20 09:34 +0200, Miro Hrončok wrote:

On 29. 05. 20 9:32, Felix Schwarz wrote:


Am 29.05.20 um 09:19 schrieb Miro Hrončok:

The side tag is being merged right now.


Thank you for all the work (also in advance with all the 
alpha/beta versions) :-)


Seems like quite a few Python packages were rebuilt in rawhide during your
mass rebuild. Did that happen in the past as well? (I don't remember it that
way but also I did not monitor previous python rebuilds closely).


In previous upgrades, we haven't checked and after we asked releng 
to merge the side tag, we just realized several packages were 
rebuilt (incl. a small boostrap loop once and anaconda the other 
time). Hence this time, I've been monitoring the situation. Less 
then 10 packages were bumped and built in rawhide during the 
rebuilds this time.


Could you send me the list of those packages, if you have it?


I've rebuilt them all again.


Are any of them in the list of packages that I need to rebuild anyway
for the boost1.73+python3.9 combo?


No.


OK, great, nothing extra for me to do then :-)


By the way, I accidentally rebuilt player in the f33-boost side tag,
because my makefile incorrectly listed it as a prerequisite of gazebo
and so automatically added it to my rebuilds (it *is* a prerequisite
of gazebo, but doesn't use boost so I didn't need to do it). I noticed
that your f33-python build of player didn't work, so I'll add that to
the list of ones to rebuild in my tag after f33-python finishes
merging (apparently they're still being signed).


The signing is taking ages :/


Yes, but python3-3.8.3-1.fc33 is done, so I'll rebuild boost in my
side tag and resume my rebuilds there.

___
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 1841512] [RFE] EPEL-8 branch for perl-Statistics-Basic

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||1841514





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1841514
[Bug 1841514] [RFE] EPEL-8 branch for perl-Bytes-Random-Secure
-- 
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 1841514] [RFE] EPEL-8 branch for perl-Bytes-Random-Secure

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||1841308
 Depends On||1841510, 1841512
   Doc Type|--- |If docs needed, set a value





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1841308
[Bug 1841308] remove hardcoded requirement for Crypt::Random
https://bugzilla.redhat.com/show_bug.cgi?id=1841510
[Bug 1841510] [RFE] EPEL-8 branch for perl-Crypt-Random-Seed
https://bugzilla.redhat.com/show_bug.cgi?id=1841512
[Bug 1841512] [RFE] EPEL-8 branch for perl-Statistics-Basic
-- 
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 1841514] New: [RFE] EPEL-8 branch for perl-Bytes-Random-Secure

[bugzilla]

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

Bug ID: 1841514
   Summary: [RFE] EPEL-8 branch for perl-Bytes-Random-Secure
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Bytes-Random-Secure
  Assignee: ppi...@redhat.com
  Reporter: p...@city-fan.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, dd...@cpan.org,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Please consider building perl-Bytes-Random-Secure for EPEL-8. It is needed for
perl-Crypt-PWSafe3.


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

Fwd: Re: late generation of assemble code

[Paul Dufresne via devel]

had forgotten to reply also to the list... doing it now:

[cut the part where it was suggested to make package that contains LLVM 
Intermediate Representation bitcode rather than CPU specific assembler]



On 2020-05-29 1:01 a.m., John M. Harris Jr wrote:

Paul,
What benefit do you see in the overhead of LLVM IR, compared to standard
packages?


John,

Where do you see overhead in the distribution of LLVM IR?

Advantages:

* more space on the hard disks of the servers, because they contains 
repositories only for LLVM IR packages rather than one by supported 
architectures


* less use of the CPU time of the servers because they don't optimize 
code for specific CPUs


* very reduced cost for supporting more architectures, as code is 
client-side generated


* faster code on clients with recent CPUs, because code is optimized for 
them, and was not in the old way of doing because you had to distribute 
for a common base CPU


* CPU specific code generation and optimizations can be done on idle 
time of the clients... there is not much idle time of the servers



___
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 1841508] [RFE] EPEL-8 branch for perl-Number-Format

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||1841512





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1841512
[Bug 1841512] [RFE] EPEL-8 branch for perl-Statistics-Basic
-- 
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 1841512] [RFE] EPEL-8 branch for perl-Statistics-Basic

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Depends On||1841508
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Paul Howarth  ---
Petr, I don't think David is around any more; would you consider taking this
one?



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1841508
[Bug 1841508] [RFE] EPEL-8 branch for perl-Number-Format
-- 
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 1841512] New: [RFE] EPEL-8 branch for perl-Statistics-Basic

[bugzilla]

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

Bug ID: 1841512
   Summary: [RFE] EPEL-8 branch for perl-Statistics-Basic
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Statistics-Basic
  Assignee: dd...@cpan.org
  Reporter: p...@city-fan.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Please consider building perl-Statistics-Basic for EPEL-8. It is needed for
perl-Bytes-Random-Secure.


-- 
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 1841510] New: [RFE] EPEL-8 branch for perl-Crypt-Random-Seed

[bugzilla]

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

Bug ID: 1841510
   Summary: [RFE] EPEL-8 branch for perl-Crypt-Random-Seed
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Crypt-Random-Seed
  Assignee: ppi...@redhat.com
  Reporter: p...@city-fan.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, dd...@cpan.org,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Please consider building this for EPEL-8. It is needed for
perl-Bytes-Random-Secure.


-- 
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 1841508] [RFE] EPEL-8 branch for perl-Number-Format

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Paul Howarth  ---
Jitka, I don't think David is around any more - would you consider taking this
yourself?


-- 
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 1841508] New: [RFE] EPEL-8 branch for perl-Number-Format

[bugzilla]

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

Bug ID: 1841508
   Summary: [RFE] EPEL-8 branch for perl-Number-Format
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Number-Format
  Assignee: dd...@cpan.org
  Reporter: p...@city-fan.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, iarn...@gmail.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Please consider branching and building perl-Number-Format for EPEL-8. It is
needed by perl-Statistics-Basic.

I would be happy to maintain this myself (FAS: pghmcfc) if you are not
interested.


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

Fedora-Cloud-32-20200529.0 compose check report

[Fedora compose checker]

No missing expected images.

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

ID: 607016  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/607016
-- 
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

On 29. 05. 20 11:49, Jonathan Wakely wrote:

On 29/05/20 09:34 +0200, Miro Hrončok wrote:

On 29. 05. 20 9:32, Felix Schwarz wrote:


Am 29.05.20 um 09:19 schrieb Miro Hrončok:

The side tag is being merged right now.


Thank you for all the work (also in advance with all the alpha/beta versions) 
:-)


Seems like quite a few Python packages were rebuilt in rawhide during your
mass rebuild. Did that happen in the past as well? (I don't remember it that
way but also I did not monitor previous python rebuilds closely).


In previous upgrades, we haven't checked and after we asked releng to merge 
the side tag, we just realized several packages were rebuilt (incl. a small 
boostrap loop once and anaconda the other time). Hence this time, I've been 
monitoring the situation. Less then 10 packages were bumped and built in 
rawhide during the rebuilds this time.


Could you send me the list of those packages, if you have it?


I've rebuilt them all again.


Are any of them in the list of packages that I need to rebuild anyway
for the boost1.73+python3.9 combo?


No.


By the way, I accidentally rebuilt player in the f33-boost side tag,
because my makefile incorrectly listed it as a prerequisite of gazebo
and so automatically added it to my rebuilds (it *is* a prerequisite
of gazebo, but doesn't use boost so I didn't need to do it). I noticed
that your f33-python build of player didn't work, so I'll add that to
the list of ones to rebuild in my tag after f33-python finishes
merging (apparently they're still being signed).


The signing is taking ages :/

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

[Bug 1841262] please build for perl-Crypt-Random for epel8

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WONTFIX
Last Closed||2020-05-29 10:16:43



--- Comment #6 from Paul Howarth  ---
Moving to Bug #1841308


-- 
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 1841308] remove hardcoded requirement for Crypt::Random

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

Link ID||Github
   ||TLINDEN/Crypt--PWSafe3/pull
   ||/11




-- 
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Jonathan Wakely]

On 29/05/20 09:34 +0200, Miro Hrončok wrote:

On 29. 05. 20 9:32, Felix Schwarz wrote:


Am 29.05.20 um 09:19 schrieb Miro Hrončok:

The side tag is being merged right now.


Thank you for all the work (also in advance with all the alpha/beta versions) 
:-)

Seems like quite a few Python packages were rebuilt in rawhide during your
mass rebuild. Did that happen in the past as well? (I don't remember it that
way but also I did not monitor previous python rebuilds closely).


In previous upgrades, we haven't checked and after we asked releng to 
merge the side tag, we just realized several packages were rebuilt 
(incl. a small boostrap loop once and anaconda the other time). Hence 
this time, I've been monitoring the situation. Less then 10 packages 
were bumped and built in rawhide during the rebuilds this time.


Could you send me the list of those packages, if you have it?

Are any of them in the list of packages that I need to rebuild anyway
for the boost1.73+python3.9 combo?

By the way, I accidentally rebuilt player in the f33-boost side tag,
because my makefile incorrectly listed it as a prerequisite of gazebo
and so automatically added it to my rebuilds (it *is* a prerequisite
of gazebo, but doesn't use boost so I didn't need to do it). I noticed
that your f33-python build of player didn't work, so I'll add that to
the list of ones to rebuild in my tag after f33-python finishes
merging (apparently they're still being signed).


___
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 1841308] remove hardcoded requirement for Crypt::Random

[bugzilla]

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



--- Comment #2 from Paul Howarth  ---
This looks like it would work but you seem to have changed the
Bytes::Random::Secure version requirement from 0.09 to 0.29 for some reason?


-- 
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 1841262] please build for perl-Crypt-Random for epel8

[bugzilla]

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



--- Comment #5 from Paul Howarth  ---
PR for Crypt-PWSafe3:
https://github.com/TLINDEN/Crypt--PWSafe3/pull/11


-- 
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 Self-Contained Change proposal: Drop mod_php

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2020-05-29 at 01:00 -0700, John M. Harris Jr wrote:
> On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
> > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
> > 
> > > Please do not drop mod_php. It is NOT the case that "php-fpm is
> > > already
> > > used  but most users of httpd and nginx without any issue."
> > 
> > php-fpm is the default configuration for httpd and nginx for few
> > versions
> > 
> > nginx ONLY uses php-fpm
> > 
> > mod_php is httpd only and prefork mode only
> > so without threaded MPM and without http2 support
> > 
> > Please describe issues, I don't have any bug report about this.
> > 
> > Remi
> 
> Yes, nginx only uses php-fpm. But that has nothing to do with
> mod_php.
> 
> The default doesn't matter, there's absolutely no reason to take away
> the 
> sysadmin's choice here. There are at least 40 servers I personally
> am 
> responsible for where I see no reason to move from mod_php to php-
> fpm, for 
> example. If you don't want to maintain it, I'd be happy to do so.
> Many third 
> party packages expect mod_php, and nearly all documentation for
> configuring 
> httpd for Fedora, CentOS and RHEL goes through the use of mod_php.
> There is 
> just no reason to break this. People who want php-fpm will stick with
> it, and 
> others will continue to use mod_php as we have for the last decade+.
> Many 
> servers do not need http2, or other new features. Many of us have
> something 
> that works, and we'd like to keep it working.

That's what CentOS / RHEL is for.

> -- 
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Qxr4ACgkQEV1auJxc
Hh6GIRAAt5sV7J4E6W5vzHCc3iy+IGXYyMtl/RqewhkcHChT5ZuiCLnOqmBw0vbF
Mrmn+6hyJUoP4Vfw1uRjbqvt5b3/0V+43ZibIwDNwi7jGSPVazgHUTdhvgqEiqhK
+tWfLrwaoLMQZoCvMNFqoRnKvmDN/go1IhmHj7HAhhb6VLmGeJ2RJCqQH9hgMUwv
9P+aUGoqO5XDFApCGtU55dtIIecPiN5Sd+lHvFRxI5cTJafsU1cLjtqvmayVaPH2
jeS5nOEFauCuZztCrYBgwgB1OKKudfj9skkb3KlH5VzoH4uSxli4xUccYFnu3Nnq
uz3J7L4W4sVc5cuhOZuQ+0GmKImY1bfrEj8FFhaVfLPU7qIXPe2zXVWrMC0FaBuD
Vtkb3d+++Pfmz2Hbs8O9ufo8ahya751f55BQrJOkLq9ncyDjyUCXgmV6Uef+VSJM
BuHRJjLTmH2i14z4hLNaila0QqOzPEg4ZpjlSOe4U1hG0UMkWqU/U3WGhTBw3dki
4sDGon85M1VOw3kDf9wyLzq0fUOvyFLOnDDewwxprWzB0W5J1j30reF9mnAiTzdJ
mOOas+n8tLNYfCpMkClmg1YB8gO6AFdvD+45GTseYOzGo4hkBcsQcCbj1uQCi7rf
0W2MVWh5ioeluvA47/x9WbSEJ6sBrVMSoBp9lW7bDEb+WBm85cA=
=oY/3
-END 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 Self-Contained Change proposal: Drop mod_php

[Neal Gompa]

On Fri, May 29, 2020 at 4:01 AM John M. Harris Jr  wrote:
>
> On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
> > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
> >
> > > Please do not drop mod_php. It is NOT the case that "php-fpm is already
> > > used  but most users of httpd and nginx without any issue."
> >
> >
> > php-fpm is the default configuration for httpd and nginx for few versions
> >
> > nginx ONLY uses php-fpm
> >
> > mod_php is httpd only and prefork mode only
> > so without threaded MPM and without http2 support
> >
> > Please describe issues, I don't have any bug report about this.
> >
> > Remi
>
> Yes, nginx only uses php-fpm. But that has nothing to do with mod_php.
>
> The default doesn't matter, there's absolutely no reason to take away the
> sysadmin's choice here. There are at least 40 servers I personally am
> responsible for where I see no reason to move from mod_php to php-fpm, for
> example. If you don't want to maintain it, I'd be happy to do so. Many third
> party packages expect mod_php, and nearly all documentation for configuring
> httpd for Fedora, CentOS and RHEL goes through the use of mod_php. There is
> just no reason to break this. People who want php-fpm will stick with it, and
> others will continue to use mod_php as we have for the last decade+. Many
> servers do not need http2, or other new features. Many of us have something
> that works, and we'd like to keep it working.
>

As an (oft forgotten!) member of the PHP SIG, I'd like to point out
that part of what we're supposed to do is ship a PHP stack that
minimizes footguns and security nightmares. The PHP stack doesn't make
this easy as it is, and it's been relatively well-known for a while
now that running the interpreter in the same process as the webserver
is a bad idea. Virtually all other programming languages have made
that change in various forms: Python now works through WSGI or ASGI,
Perl uses either PSGI or CGI, Ruby operates through either Unicorn or
Puma typically, and for the past ten years, PHP has strongly
recommended using FastCGI or CGI over mod_php.

It is absolutely a good idea to take away this choice from our builds
when the advice from framework developers, ecosystem experts, and the
upstream developers is to *not* use mod_php. Fedora is in the business
of providing sane defaults and a high-quality package collection. Part
of the quality is removing footguns when they don't need to exist
anymore. We haven't shipped mod_php as the default setup for Apache +
php for several years now, as part of a plan to eventually get rid of
it.



-- 
真実はいつも一つ！/ 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 Self-Contained Change proposal: Drop mod_php

[John M. Harris Jr]

On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
> Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
> 
> > Please do not drop mod_php. It is NOT the case that "php-fpm is already
> > used  but most users of httpd and nginx without any issue."
> 
> 
> php-fpm is the default configuration for httpd and nginx for few versions
> 
> nginx ONLY uses php-fpm
> 
> mod_php is httpd only and prefork mode only
> so without threaded MPM and without http2 support
> 
> Please describe issues, I don't have any bug report about this.
> 
> Remi

Yes, nginx only uses php-fpm. But that has nothing to do with mod_php.

The default doesn't matter, there's absolutely no reason to take away the 
sysadmin's choice here. There are at least 40 servers I personally am 
responsible for where I see no reason to move from mod_php to php-fpm, for 
example. If you don't want to maintain it, I'd be happy to do so. Many third 
party packages expect mod_php, and nearly all documentation for configuring 
httpd for Fedora, CentOS and RHEL goes through the use of mod_php. There is 
just no reason to break this. People who want php-fpm will stick with it, and 
others will continue to use mod_php as we have for the last decade+. Many 
servers do not need http2, or other new features. Many of us have something 
that works, and we'd like to keep it working.

-- 
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

On 29. 05. 20 9:32, Felix Schwarz wrote:


Am 29.05.20 um 09:19 schrieb Miro Hrončok:

The side tag is being merged right now.


Thank you for all the work (also in advance with all the alpha/beta versions) 
:-)

Seems like quite a few Python packages were rebuilt in rawhide during your
mass rebuild. Did that happen in the past as well? (I don't remember it that
way but also I did not monitor previous python rebuilds closely).


In previous upgrades, we haven't checked and after we asked releng to merge the 
side tag, we just realized several packages were rebuilt (incl. a small boostrap 
loop once and anaconda the other time). Hence this time, I've been monitoring 
the situation. Less then 10 packages were bumped and built in rawhide during the 
rebuilds this time.


--
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Felix Schwarz]

Am 29.05.20 um 09:19 schrieb Miro Hrončok:
> The side tag is being merged right now.

Thank you for all the work (also in advance with all the alpha/beta versions) 
:-)

Seems like quite a few Python packages were rebuilt in rawhide during your
mass rebuild. Did that happen in the past as well? (I don't remember it that
way but also I did not monitor previous python rebuilds closely).

Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 System-Wide Change proposal: NSS CK_GCM_PARAMS change

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 28, 2020 at 03:46:25PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/NssGCMParams
> 
> == Summary ==
> Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to
> change the definition of CK_GCM_PARAMS in a source incompatible way.
> Upstream made this change in NSS 3.52.

When I'm reading this description, it feels like it was written by
somebody deep in the subject, but Change pages need to be accessible
to a general audience, even people who don't program in C. They should
be able to get the gist without having to absorb all the details.

It'd help if this summary mentioned that CK_GCM_PARAMS is a struct
definition and that a new field was added (if I got that right) and that
end programs need to adjust by changing how they do [what?].

> == Owner ==
> * Name: [[User:rrelyea| Bob Relyea]]
> * Email: rrel...@redhat.com
> 
> 
> == Detailed Description ==
> PKCS #11 2.40 had a mismatch between the SPEC and the released header
> file for CK_GCM_PARAMS. The latter is controlling. We created or
> header based on the former. In PKCS #11 v3.0 the reconciled this, but
> it left us with. The new (to NSS) definition has a new field ulIvBits,
> which must be set correctly.

This part is very hard to grok. Is the capitalized "SPEC" an abbreviation?
One of the sentences ends mid-sentence. Also "must be set correctly"
by whom, how?

> To solve this, the NSS 3.52 headers has both definitions:
> CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3
> is the new (to NSS) definition. CK_GCM_PARAMS takes on one or the
> other based on the definition of NSS_PKCS11_2_0_COMPAT.
> 
> The current NSS builds in fedora have changes the sense of this
> #define to NSS_PKCS11_3_0_STRICT to get the new behavior, and keep the
> old behavior by default. NSS builds will automatically switch back to
> the upstream default in Fedora 34. None of the changes below actually
> requires setting the NSS_PKCS11_3_STRICT define, though doing so can
> test that all but option 1 is functioning.
> 
> Applications can fix this the following ways:
> 
> option 1
> 
>  #define NSS_PKCS11_2_0_COMPAT 1
> 
> or compile with -DNSS_PKCS11_2_0_COMPAT
> 
> your app will compile and run using current and older versions of NSS,
> but may break on newer tokens that use the new definition (same as the
> previous behavior.
> 
> ---
> 
> option 2
> 
> rename CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss
> >= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT).
> Like option 2 it may break on newer tokens.

What does "rename" mean in this context? Based on the earlier text, I
thought CK_GCM_PARAMS was a structure...

> --
> 
> option 3
> 
> rename CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.
> 
> This will require nss >= 3.52 to compile and to run. Should run on all
> run tokens.
> 
> -
> 
> option 4
> 
> Move to PK11_AEADOp  interface, which all requires nss >= 3.52 to
> compile and run,  but it's less surprising and the dependency will be
> picked up automatically because you are using a new for 3.52
> interface.
> --
> 
> Option 4 is the preferred solution. It takes advantage the the PKCS
> #11 v3 interface for  AES_GCM while removing any PCKS #11 param
> structure dependency in the application. It also handles backward
> compatibility on older tokens and automatically detects which flavor
> of data structure is supported. It also would help with applications
> that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY.
> 
> == Benefit to Fedora ==
> This change will keep fedora with the NSS upstream as well as make
> Fedora compliant with the official OASIS PKCS #11 spec.
> 
> == Scope ==
> * Proposal owners: NSS 3.52 has already had builds made with the
> reverse sense. NSS will need to be rebuilt at the start of Fedora 34.
> 
> * Other developers:  Developers need to choose one of these options by
> fedora 34 or their rebuilt packages will fail at runtime.

The text from above starts repeating here?

> option 1
> 
>  #define NSS_PKCS11_2_0_COMPAT 1
> 
> or compile with -DNSS_PKCS11_2_0_COMPAT
> 
> your app will compile and run using current and older versions of NSS,
> but may break on newer tokens that use the new definition (same as the
> previous behavior.
> 
> ---
> 
> option 2
> 
> rename CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss
> >= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT).
> Like option 2 it may break on newer tokens.
> 
> --
> 
> option 3
> 
> rename CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.
> 
> This will require nss >= 3.52 to 

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a 
side tag.


     https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.

If you'd like to build the package, you should be able to build it in the side 
tag via:


     on branch master:
     $ fedpkg build --target=f33-python
     $ koji wait-repo f33-python --build 

Note that it will take a while before all the essential packages are rebuilt, so 
don't except all your dependencies to be available right away. When in trouble, 
ask here or on IRC (#fedora-python on Freenode).


Builds: 
https://koji.fedoraproject.org/koji/builds?latest=0=22287=-build_id=0 



Please avoid any potentially disturbing changes in Python packages until the 
rebuild is over.


The side tag is being merged right now.

The builds are tagged into f33 in alphabetical order, hence expect a small 
window of very broken dependencies.


--
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 Self-Contained Change proposal: Drop mod_php

[Remi Collet]

Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
> Please do not drop mod_php. It is NOT the case that "php-fpm is already used 
> but most users of httpd and nginx without any issue."

php-fpm is the default configuration for httpd and nginx for few versions

nginx ONLY uses php-fpm

mod_php is httpd only and prefork mode only
so without threaded MPM and without http2 support

Please describe issues, I don't have any bug report about this.

Remi
___
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