date:20210208

No missing expected images.

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

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

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

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

[389-devel] 389 DS nightly 2021-02-09 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/09/report-389-ds-base-2.0.2-20210209git4f22163e6.fc33.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

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 7:13 PM Kevin Kofler via devel
 wrote:
>
> Chris Murphy wrote:
> > If you want to take the risk of acquiring a rootkit that can
> > permanently take control of your firmware, that is up to you. It
> > should not be a distribution recommendation to subject users to such
> > bad advice.
>
> And the "good advice" would be to accept that your computer will only run
> operating systems approved by Microsoft and to accept a security model that
> prevents basic functionality such as hibernation, third-party kernel
> modules, etc.?

This is such an old argument. I know you've been around in Fedora long
enough to actually understand this stuff if you really wanted to at
least not spread misinformation.

Microsoft does not approve or disapprove of operating systems. They
have an EFI signing program for developers. They are signing just our
shim bootloader. Fedora signs the other things in the boot chain.

Anyone can enroll their own signing keys with the firmware, sign the
bootloader, kernel and kernel modules, including 3rd party. You can
even mix and match signed binaries. And those binaries will comply
with a Secure Boot enabled system just fine, without having Microsoft
signatures on anything. Yes that's tedious and it would be better if
it were easier than it is right now.

Windows supports hibernation, with UEFI Secure Boot enabled. We don't
because Linux hibernation images are inherently insecure by design and
thus are a loophole for thwarting the Secure Boot regime. Therefore a
kernel lockdown policy is applied to disallow hibernation if Secure
Boot is enabled. It can be fixed, but the resources to finish that
work have not yet materialized.

Literally none of this is Microsoft's fault. And rootkits predate UEFI.

-- 
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: New memory tester application potentially to replace memtest86+: PCMemTest

2021-02-08 Thread Neal Gompa

On Mon, Feb 8, 2021 at 9:13 PM Kevin Kofler via devel
 wrote:
>
> Chris Murphy wrote:
> > If you want to take the risk of acquiring a rootkit that can
> > permanently take control of your firmware, that is up to you. It
> > should not be a distribution recommendation to subject users to such
> > bad advice.
>
> And the "good advice" would be to accept that your computer will only run
> operating systems approved by Microsoft and to accept a security model that
> prevents basic functionality such as hibernation, third-party kernel
> modules, etc.?
>

Don't blame Microsoft for our failings. The fact that we can't do
hibernation or offer an easy path for third-party kernel modules to
function in a Secure Boot environment is *entirely* our fault. After
shim->grub2, Microsoft's trust ends and ours begins. We use *our*
certificate from GRUB onward.

The fact that hibernation is broken in Secure Boot is entirely the
fault of the engineers that were in charge of developing the Fedora
kernel and bootloader security mechanism, because they created the
patch set that made it functionally impossible to make it work. That
is, it's the LOCKDOWN feature layered on Secure Boot, not Secure Boot
itself. It's obvious Secure Boot itself is no impediment to
hibernation, since both Windows and macOS (both users of Secure Boot)
can do hibernation just fine.

The fact that third-party kernel modules are nearly impossible to set
up in Secure Boot is entirely the fault of engineers who designed the
certificate trust mechanism to not offer a path for semi-interactive
or non-interactive trust scenarios like we have for package and
repository signatures. It is theoretically possible for third-party
stuff to work in a Secure Boot environment, but the path to get there
is so onerous because nobody who makes this stuff for Linux cares to
make this easy to work with. The trust mechanisms for Secure Boot are
not fundamentally any different from how trust works for GPG (they're
both rooted in PKI architectures). The difference is that expanding
trust at the Linux kernel level is deliberately under-documented and
considered unsupported. Additionally, creating signed kernel module
packages has been broken since the beginning, since nobody cared to
actually *fix* the kernel module packaging system to account for it.

I've been trying to untangle this mess for months because I'm
frustrated by how stupid the situation is and how we've never *tried*
to make having a secure system easier.

None of this had to be this way. It is so by our own inaction, not by
the action of Microsoft.

> And for the record, my computer's UEFI firmware is so old that "Secure Boot"
> cannot even be enabled at all, even if I wanted to.
>

Meh. That means your computer was made before Microsoft started having
vendors require UEFI firmware to include their keys for Windows
certification (which was in 2006/2007). I'm surprised it still works.
More power to you, I guess?

-- 
真実はいつも一つ！/ 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: New memory tester application potentially to replace memtest86+: PCMemTest

Chris Murphy wrote:
> If you want to take the risk of acquiring a rootkit that can
> permanently take control of your firmware, that is up to you. It
> should not be a distribution recommendation to subject users to such
> bad advice.

And the "good advice" would be to accept that your computer will only run 
operating systems approved by Microsoft and to accept a security model that 
prevents basic functionality such as hibernation, third-party kernel 
modules, etc.?

And for the record, my computer's UEFI firmware is so old that "Secure Boot" 
cannot even be enabled at all, even if I wanted to.

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

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 5:19 PM Kevin Kofler via devel
 wrote:
>
> Chris Murphy wrote:
> > Yeah I definitely do not want Fedora in a position where anyone has to
> > give users advice like "you need to disable UEFI Secure Boot" in order
> > to do X. Be it testing RAM or anything else.
>
> Why would anyone want to NOT disable Restricted Boot? (Assuming the firmware
> is not broken and lets them disable it, as it is supposed to.)

If you want to take the risk of acquiring a rootkit that can
permanently take control of your firmware, that is up to you. It
should not be a distribution recommendation to subject users to such
bad advice.


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

[Bug 1922743] perlbrew-0.91 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perlbrew-0.91-1.fc34|perlbrew-0.91-1.fc34
   ||perlbrew-0.91-1.fc33
 Resolution|--- |ERRATA
Last Closed||2021-02-09 00:56:32



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-4ec9940789 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1922014] perlbrew-0.90 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perlbrew-0.90-1.fc34|perlbrew-0.90-1.fc34
   ||perlbrew-0.91-1.fc33
 Resolution|--- |ERRATA
Last Closed|2021-01-29 11:50:52 |2021-02-09 00:56:30



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-4ec9940789 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)

2021-02-08 Thread Robbie Harwood

Miro Hrončok  writes:

> On 08. 02. 21 20:38, Robbie Harwood wrote:
>> Robbie Harwood  writes:
>> 
>>> Ben Cotton  writes:
>>>
 A simple `sed` can be applied in `%prep` as a temporary (or even
 permanent) downstream solution.

 In most cases, performing the following replacement should be enough:

   s/^(\s*)import mock/\1from unittest import mock/
   s/^(\s*)from mock import /\1from unittest.mock import /
>>>
>>> a couple lines of sed to all (affected) specfiles.  I hope I have
>>> misunderstood, because that has no mechanism to get the changes back
>>> into upstreams.  Could you clarify what you intend to do?
>> 
>> Turns out this is indeed what they meant.  I would like to reiterate
>> my concern that this has no mechanism to get the changes back into
>> upstreams: it's just Fedora deviating further from the rest of the
>> world, not leading the charge.
>
> Not sure who you mean by "them" in this case,

Change authors.  So, you.

> but doing this downstream only was never my intention. I am the change
> owner.

You have already replied to one of the PRs
https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1
to comment that it couldn't be merged.  It follows the downstream-only
sed approach, you'll note.

Thanks,
--Robbie


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

Re: New memory tester application potentially to replace memtest86+: PCMemTest

Chris Murphy wrote:
> Yeah I definitely do not want Fedora in a position where anyone has to
> give users advice like "you need to disable UEFI Secure Boot" in order
> to do X. Be it testing RAM or anything else.

Why would anyone want to NOT disable Restricted Boot? (Assuming the firmware 
is not broken and lets them disable it, as it is supposed to.)

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

Re: Fedora 34 Mass Branching

2021-02-08 Thread Petr Menšík

Hi,

I were unable to find time in the schedule, at which the new F35 GPG key
would be activated to sign new builds.

In order to prevent bug 1872248 [1], new key must not be used until all
stable releases got new key with symlinks for all supported arches. New
builds were done few days ago, f33 is already in stable [2]. Yet it is
again incomplete and unusable. If the new key is activated now, it would
break (again!) gpg validation of rpm updates.

Please tell me I am missing something. I tried to help with fixing this
state, yet my PR[3] are still not merged. Could be new GPG key
activation explicitly mentioned in the schedule? Isn't it also the key step?

So, how does Rawhide choose GPG key to sign built packages? Would it
break (again) today?

Regards,
Petr

1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248
2. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d17f7e917c
3. https://src.fedoraproject.org/rpms/fedora-repos/pull-requests

On 2/8/21 5:39 PM, Mohan Boddu wrote:
> Hello All,
> 
> Fedora 34 will be branched from rawhide on Feb 09th 2021 as per the
> Fedora 34 schedule[1]. The process takes about a day and everything
> should be ready by Feb 10th 2021. You can still be able to build
> packages normally until then, but after the mass branching, rawhide
> and F34 will be separated.
> 
> We will send another email once the branching is done.
> 
> Thanks,
> Mohan Boddu.
> 
> [1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

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

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

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 4:47 PM Martin Whitaker
 wrote:
>
> On 07/02/2021 22:23, Chris Murphy wrote:
> > On Sun, Feb 7, 2021 at 2:08 AM Neal Gompa  wrote:
> >>
> >> Hey all,
> >>
> >> I discovered today that there's a new replacement for memtest86+ that
> >> appears to even have UEFI support called PCMemTest[0].
> >>
> >> The main reason I call out to this is because we don't have a memory
> >> tester offering in our UEFI boot variant for the Fedora live media,
> >> and this is actively maintained (unlike memtest86+, which we currently
> >> use...).
> >>
> >> Mageia is shipping this starting with Mageia 8[1], and we should
> >> consider shipping this with Fedora 34.
> >
> >
> > * A listed limitation: "When booted on a UEFI system, keyboard input
> > will only be seen if the CSM is enabled in the BIOS. Without this, the
> > test will run, but you will be unable to alter the configuration."
> >
> > - How does a CSM provide keyboard input to an EFI application? Or does
> > this mean with CSM enabled, we'd use the BIOS version of the memory
> > tester; and with CSM disabled, we'd use the UEFI version of the memory
> > tester?
>
> On all the machines in my possession, enabling the CSM enables emulation
> of the keyboard controller ports (ports 0x60 and 0x64), even when booted
> in UEFI mode. That may not be true for all BIOSs of course.

OK. I'm confused (not unusual) and also ignorant of how the keyboard
driver situation works on UEFI without the CSM enabled. Because
without it enabled, I definitely have working keyboard on all my
systems in EFI shell. That suggests the keyboard driver is available,
isn't due to GRUB providing one.

I see GRUB has usb_keyboard.mod but I don't see it as one of the
modules we're baking into Fedora's grubx64.efi.
https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub.macros

I guess I'm trying to figure out the scope of the "does not have
working keyboard with native UEFI plus Secure Boot" problem.


> > - As far as I'm aware, enabling CSM requires disabling UEFI Secure Boot.
>
> Probably so. At which point you are limited to running the memory tests
> with the default configuration (which is to run all tests using a single
> processor).
>
> As I don't use secure boot, I wasn't really motivated to start writing a
> replacement keyboard driver.

Yeah I definitely do not want Fedora in a position where anyone has to
give users advice like "you need to disable UEFI Secure Boot" in order
to do X. Be it testing RAM or anything else.



-- 
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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Jonathan Wakely wrote:
> How do you get that directly from koji in a script?
> 
> Is it as easy as a single git command to check if rawhide and
> rawhide-build are the same ref?
> 
> It looks to me like I need to parse the build ID from the output of
> "koji latest-build  " and then use "koji buildinfo "
> and then parse that for the Source: line. Is there a better way?

To be honest, I don't know.

> It is if a provenpackager bumped it in the meanwhile.
> 
> Now the maintainer has to resolve the fact that they thought they'd
> pushed their work, but what they have locally isn't on the server.

They will have the same issue if the provenpackager bumped the package while 
they were working on it without the server having force-pushed anything. 
They will either way have to merge or rebase onto the server's HEAD. (IMHO, 
rebasing is the right way in this situation, and I think pull with rebase 
should be the default, but that is another topic.)

> If you are comfortable using Git, that's trivial to do. But requiring
> every maintainer to be comfortable with that would be a change.

We already require every maintainer to be comfortable with Git conflict 
management. The mere act of using Git makes that requirement. See my 
previous paragraph.

If we want to excuse maintainers from dealing with conflicts, we have to 
switch to a locking-based SCM, with all the problems and drawbacks that come 
with that. Otherwise, conflicts can and will happen, there is no (other) way 
around them.

> If they just do a git pull they're likely to get conflicts (to the
> %changelog if nothing else) to resolve. Again, many of us will be able
> %to resolve those easily. But for somebody who thought they'd pushed
> %all their changes to the server already, having to re-apply them
> %might not be trivial.

Again, the exact same thing will happen if only the concurrent change 
without the CI force push happened.

> Again, I can't believe that "rewriting git history causes issues" even
> needs explanation.

Rewinding to a previous state is a special case of rewriting history, which 
causes fewer issues than the general case.

Keep in mind that rewinding can naturally happen if the server had a disk 
failure and was restored from an old backup. Git is prepared to deal with 
that situation.

>>On the other hand, I am strongly opposed to introducing a rawhide-build
>>branch as you suggest. It does not address the problem at hand and I fail
>>to see what problem it actually addresses.
> 
> I don't need to use koji to find out the commit that built, I can just
> use git commands.

That is a feature and not by itself a solution to a problem, because you 
have not given a concrete use case for the feature. :-) But I get your 
point. Now, is it worth the implementation effort? It does not solve the 
problem that started this thread in any case.

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

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

2021-02-08 Thread Jeff Law



On 2/2/21 5:03 PM, Ian McInerney wrote:
> On Mon, Jan 4, 2021 at 7:28 PM Jeff Law  > wrote:
>
>
> snip...
> >
> > What is this macro going to be called?  I would like to get an early
> > start on updating my packages.
> No idea.  I'm open to suggestions.
>
>
> Any update on the name of this macro/its implementation? I am working
> on revising a spec file that has a static library included and if this
> macro is available to use already I would like to add it as long as I
> am working in the spec.
No movement yet.  I had to push this (and other) stuff down to deal with
a variety of F34 firedrills.  I expect to come back to it during the F35
cycle.

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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-08 Thread Troy Dawson

On Mon, Feb 8, 2021 at 11:50 AM Kevin Fenzi  wrote:
>
> On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote:
> > There is a little nuance here. In order to get the repository going, we had
> > to 'mass-branch' about 40 or so packages. fedpkg and some other items
> > require quite a few packages which all have to be done at once. Without
> > those you can't build anything else to put into EPEL... so I would say that
> > EPEL is the specific set of packages in order to get a minimal repository
> > working in the Fedora Build System. Everything else is just extras people
> > add to it.
>
> That is an excellent point. Perhaps we should try and identify those
> packages and see if we can just add epel-packagers sig to all of them?
> Do we have any record of those?
>
If they were the packages that I built they were
fedpkg
koji
bodhi

And then all the packages needed to build them, that weren't in RHEL.
But there might have been others that Smooge did.

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

Re: Fedora 34 Mass Rebuild


On 08/02/21 14:40 +0100, Milan Crha wrote:

On Mon, 2021-02-01 at 15:03 -0500, Mohan Boddu wrote:

Fedora 34 mass rebuild of rpms is done


Hi,
I just noticed that syncevolution built just fine on the January 30th,
but it is failing to build right now, using the same sources as releng.
I opened [1] for it.

It kind of scares me, I do not know how to decipher it. Is it that the
mass rebuild was not done against proper packages?


No, it's simply that glib2 was changed a few days ago, after the mass
rebuild. The syncevolution sources didn't change, but some of the
headers it depends on did change.
___
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

linux-firmware heads up for brcmfmac wifi firmware

2021-02-08 Thread Peter Robinson

Hi All,

Just a heads up for those that have a brcmfmac, the Cypress variants
of these WiFi modules (there's 3 vendors that make them: Broadcom,
Cypress/Infineon and now Synaptics) have got new firmwares, I'm giving
a heads up because in some cases the firmwares are being updated from
firmwares that date back to 2014 so no doubt there's quite some
changes here.

If you run into a problem just report it in bugzilla in the usual manner.

On the plus side there's at least one CVE I'm aware of and for some of
the older firmwares I've little doubt there's quite a few more.
___
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 Change: Deprecate python-mock (Self-Contained change proposal)


On 08. 02. 21 22:43, Miro Hrončok wrote:

On 08. 02. 21 20:38, Robbie Harwood wrote:

Robbie Harwood  writes:


Ben Cotton  writes:


A simple `sed` can be applied in `%prep` as a temporary (or even
permanent) downstream solution.

In most cases, performing the following replacement should be enough:

  s/^(\s*)import mock/\1from unittest import mock/
  s/^(\s*)from mock import /\1from unittest.mock import /


a couple lines of sed to all (affected) specfiles.  I hope I have
misunderstood, because that has no mechanism to get the changes back
into upstreams.  Could you clarify what you intend to do?


Turns out this is indeed what they meant.  I would like to reiterate
my concern that this has no mechanism to get the changes back into
upstreams: it's just Fedora deviating further from the rest of the
world, not leading the charge.


Not sure who you mean by "them" in this case, but doing this downstream only was 
never my intention. I am the change owner.


Neither is a provenpackager adding the sed to all (affected) specfiles.

--
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 Change: Deprecate python-mock (Self-Contained change proposal)


On 08. 02. 21 20:38, Robbie Harwood wrote:

Robbie Harwood  writes:


Ben Cotton  writes:


A simple `sed` can be applied in `%prep` as a temporary (or even
permanent) downstream solution.

In most cases, performing the following replacement should be enough:

  s/^(\s*)import mock/\1from unittest import mock/
  s/^(\s*)from mock import /\1from unittest.mock import /


a couple lines of sed to all (affected) specfiles.  I hope I have
misunderstood, because that has no mechanism to get the changes back
into upstreams.  Could you clarify what you intend to do?


Turns out this is indeed what they meant.  I would like to reiterate
my concern that this has no mechanism to get the changes back into
upstreams: it's just Fedora deviating further from the rest of the
world, not leading the charge.


Not sure who you mean by "them" in this case, but doing this downstream only was 
never my intention. I am the change owner.


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

[EPEL-devel] Re: Proposal: EPEL9 timeline


On 08. 02. 21 14:19, Stephen John Smoogen wrote:
There is a little nuance here. In order to get the repository going, we had to 
'mass-branch' about 40 or so packages. fedpkg and some other items require quite 
a few packages which all have to be done at once. Without those you can't build 
anything else to put into EPEL... so I would say that EPEL is the specific set 
of packages in order to get a minimal repository working in the Fedora Build 
System. Everything else is just extras people add to it.


Is this needed to allow building EPEL 9 packages from RHEL 9 system? Should that 
indeed be the minimal requirement?


Because AFAIK we don't need fedpkg in EPEL 9 to build packages in mock/koji, 
just fedpkg-minimal, epel-release and epel-rpm-macros (+ eventually other epel 
packages required by that one, but I imagine that to be zero at the start).


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

Re: Orphaned packages looking for new maintainers

2021-02-08 Thread Fabio Valentini

On Mon, Feb 8, 2021 at 8:04 PM José Abílio Matos  wrote:
> Something that I am curious is that the package that was rebuilt on the mass
> rebuild does not show in the stable version of Fedora 34:
>
> https://src.fedoraproject.org/rpms/python-blinker
>
> Is this expected?

You mean it does not show up in the *table* for Fedora 34? Because
Fedora 34 is not *stable* yet :)
And yes, this is completely normal and expected, though confusing.
Builds submitted as part of mass rebuilds do not go through bodhi, and
they do not get bodhi updates associated with them.
The table that's shown for each package on src.fedoraproject.org only
knows about builds that went through bodhi, though.
https://pagure.io/pagure-dist-git/issue/128

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

Re: Orphaned packages looking for new maintainers

2021-02-08 Thread Tomasz Torcz

On Mon, Feb 08, 2021 at 07:07:40PM +0100, Miro Hrončok wrote:
> On 08. 02. 21 19:03, Gwyn Ciesla via devel wrote:
> > I believe Tomasz was asking about the many packages that indirectly require 
> > uw-imap.

  Exactly, sorry for not communicating clearly enough.
 
> Oh. Right, php indeed.

  Thanks.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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 memory tester application potentially to replace memtest86+: PCMemTest

2021-02-08 Thread Brandon Nielsen


On 2/8/21 2:44 PM, Chris Murphy wrote:

On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch  wrote:


Being devils advocate, but should we have the memtest86 or similar by
default? I have certainly not used this feature in my 10+ yeas with Fedora.



You mean get rid of it (from media and installations)? Because we
install it unconditionally already, even though it's a BIOS only
utility and there isn't a boot entry for it in the bootloader.

It's a bit obscure how to use it, given there's no menu entry for it.




There's also the fact it doesn't seem to work real well with modern 
hardware[0][1].


[0] - https://bugzilla.redhat.com/show_bug.cgi?id=1815742
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869211
___
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 memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch  wrote:
>
> Being devils advocate, but should we have the memtest86 or similar by
> default? I have certainly not used this feature in my 10+ yeas with Fedora.
>

You mean get rid of it (from media and installations)? Because we
install it unconditionally already, even though it's a BIOS only
utility and there isn't a boot entry for it in the bootloader.

It's a bit obscure how to use it, given there's no menu entry for it.

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

Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)

2021-02-08 Thread Robbie Harwood

Robbie Harwood  writes:

> Ben Cotton  writes:
>
>> A simple `sed` can be applied in `%prep` as a temporary (or even
>> permanent) downstream solution.
>>
>> In most cases, performing the following replacement should be enough:
>>
>>  s/^(\s*)import mock/\1from unittest import mock/
>>  s/^(\s*)from mock import /\1from unittest.mock import /
>
> a couple lines of sed to all (affected) specfiles.  I hope I have
> misunderstood, because that has no mechanism to get the changes back
> into upstreams.  Could you clarify what you intend to do?

Turns out this is indeed what they meant.  I would like to reiterate
my concern that this has no mechanism to get the changes back into
upstreams: it's just Fedora deviating further from the rest of the
world, not leading the charge.

Thanks,
--Robbie


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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-08 Thread Kevin Fenzi

On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote:
> There is a little nuance here. In order to get the repository going, we had
> to 'mass-branch' about 40 or so packages. fedpkg and some other items
> require quite a few packages which all have to be done at once. Without
> those you can't build anything else to put into EPEL... so I would say that
> EPEL is the specific set of packages in order to get a minimal repository
> working in the Fedora Build System. Everything else is just extras people
> add to it.

That is an excellent point. Perhaps we should try and identify those
packages and see if we can just add epel-packagers sig to all of them?
Do we have any record of those?

kevin


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

Fedora-IoT-34-20210208.0 compose check report

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 3/16 (x86_64), 5/15 (aarch64)

Old failures (same test failed in Fedora-IoT-34-20210206.0):

ID: 772291  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/772291
ID: 772300  Test: x86_64 IoT-dvd_ostree-iso podman
URL: https://openqa.fedoraproject.org/tests/772300
ID: 772301  Test: x86_64 IoT-dvd_ostree-iso podman_client
URL: https://openqa.fedoraproject.org/tests/772301
ID: 772307  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/772307
ID: 772310  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/772310
ID: 772312  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/772312
ID: 772317  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/772317
ID: 772318  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/772318

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

Old soft failures (same test soft failed in Fedora-IoT-34-20210206.0):

ID: 772292  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/772292

Passed openQA tests: 12/16 (x86_64), 10/15 (aarch64)

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.67 to 0.30
Previous test data: https://openqa.fedoraproject.org/tests/771138#downloads
Current test data: https://openqa.fedoraproject.org/tests/772305#downloads
-- 
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: Orphaned packages looking for new maintainers

2021-02-08 Thread José Abílio Matos

On Monday, February 8, 2021 5:15:13 PM WET Adam Williamson wrote:
> For the record it's also required by fedora-messaging, which is why
> just about everything else in the world needed it 

The last release is from 2015, but there are different commits over the years 
with the last being 10 days ago to the development version. The code works 
with python since 3.4, and has worked with every new python version since 
then.

Something that I am curious is that the package that was rebuilt on the mass 
rebuild does not show in the stable version of Fedora 34:

https://src.fedoraproject.org/rpms/python-blinker

Is this expected?

Regards,
-- 
José Abílio

___
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: Orphaned packages looking for new maintainers

2021-02-08 Thread Gwyn Ciesla via devel

Can uw-imap be replaced with something else, or should someone pick it up?


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

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, February 8, 2021 12:07 PM, Miro Hrončok  wrote:

> On 08. 02. 21 19:03, Gwyn Ciesla via devel wrote:
> 

> > I believe Tomasz was asking about the many packages that indirectly require 
> > uw-imap.
> 

> Oh. Right, php indeed.
> 

> -
> 

> 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



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

Fedora-Rawhide-20210208.n.0 compose check report

Missing expected images:

Xfce raw-xz armhfp
Minimal raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
8 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 22/183 (x86_64), 18/124 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210207.n.0):

ID: 771972  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/771972
ID: 771996  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/771996
ID: 771998  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/771998
ID: 772000  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/772000
ID: 772070  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/772070
ID: 772086  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/772086
ID: 772088  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/772088
ID: 772097  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/772097
ID: 772099  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/772099
ID: 772104  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/772104
ID: 772106  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/772106
ID: 772108  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/772108
ID: 772110  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/772110
ID: 772188  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/772188
ID: 772195  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/772195
ID: 772210  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/772210
ID: 772215  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/772215
ID: 772250  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/772250
ID: 772261  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/772261
ID: 772280  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/772280
ID: 772281  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/772281
ID: 772282  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/772282

Old failures (same test failed in Fedora-Rawhide-20210207.n.0):

ID: 771986  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/771986
ID: 772018  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/772018
ID: 772022  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/772022
ID: 772023  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/772023
ID: 772053  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/772053
ID: 772060  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/772060
ID: 772073  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/772073
ID: 772083  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/772083
ID: 772125  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/772125
ID: 772138  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/772138
ID: 772200  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/772200
ID: 772209  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/772209
ID: 772218  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/772218
ID: 772231  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/772231
ID: 772252  Test: aarch64

[Bug 1926383] New: perl-BibTeX-Parser-1.03 is available

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

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



Latest upstream release: 1.03
Current version/release in rawhide: 1.02-11.fc34
URL: http://search.cpan.org/dist/BibTeX-Parser/

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


-- 
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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git


On 08/02/21 10:14 -0800, Kevin Fenzi wrote:

Is there really a need for a rawhide-build branch?

What if we just pushed a tag for the commit that built after the build
finishes in koji?


In an earlier reply I did say a tag would also work.

To me, a branch ref seems more natural than a tag that keeps being
updated, but either would be fine. Git tags always seem like slightly
second class citizens compared to branches.

One minor downside of a tag is that tag updates aren't fetched if you
use --no-tags or the tagOpt config for the branch is false. I don't
use those though, so I'd be fine with a tag.

___
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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git


On 08/02/21 16:28 +0100, Kevin Kofler via devel wrote:

Jonathan Wakely wrote:

You've completely misunderstood the suggestion.


No, sorry, I understood it completely. I think that you are the one who
completely misunderstood my objection, and also missed the point of the
original post. Let me explain:


I'm suggesting that everybody pushes to rawhide just like today.
Maintainers and provenpackagers. Nothing changes in that respect. There is
a read-only branch called rawhide-build which contains the
last-known-to-build commit from rawhide. Nobody can push to rawhide-build,
it only gets updated automatically when a build completes in koji.


Yes, I got that.

But how does that address the point of the OP that provenpackagers need the
rawhide branch to be buildable so they can *automatically* bump and commit
to it?

Let's say that I am a provenpackager (which I happen to actually be) and
that I want to do a scripted mass-rebuild (which is unlikely to happen in my
case, but other provenpackagers have that need, so let's please assume it).
What value does a read-only rawhide-build branch give me? It just tells me
what was the last commit that built, an information I can just get directly
from Koji. Having this in git does not help me in any way.


How do you get that directly from koji in a script?

Is it as easy as a single git command to check if rawhide and
rawhide-build are the same ref?

It looks to me like I need to parse the build ID from the output of
"koji latest-build  " and then use "koji buildinfo "
and then parse that for the Source: line. Is there a better way?


If a maintainer wants to fix the broken state they created, they just
fix it locally and push. There's no need to reset or merge in the
revert that happened upstream (because that would be extra work for
them, and non-trivial to do right for devs who aren't comfortable with
Git beyond the basics).


And that is exactly the same as the status quo, no rawhide-build branch
needed.


If a provenpackager needs to bump and rebuild they have choices (but
none of them involve touching rawhide-build as that's read-only):


So who needs rawhide-build then?


1) Do nothing. The package is broken anyway. The maintainer needs to
fix it anyway. It will be rebuilt after they fix it. Why should the
provenpackager fix it? Often they don't need to. This is less work for
the provenpackager, and leaves the rawhide branch in the state where
the maintainer last touched it, so they can easily start fixing it.


That's what the OP explicitly does not want to do. It happens now for lack
of a better solution, but it means that packages that need to be rebuilt for
a broken dependency will be stuck with the broken dependency.


2) Proven packager *manually* does git revert for the commits that are
on rawhide but not rawhide-build (which is an easy way to know which
commits were added since the last successful build)


The whole point of this thread is that doing this manually does not scale to
a scripted mass rebuild.

And there is indeed no way to automate the general case where there can be
not only more than one commit in a linear history, but also merge commits
making the history non-linear. The only effective way (hard reset and force
push) is banned by our Git hooks.


Or soft reset to rawhide-build and commit.


That could work, even automatically, but it breaks the history by
introducing an SVN-style "merge commit" that is not really a git merge or a
git revert, but masquerades as a plain commit. And what should the commit
message be? "Revert to deadbeef1234567890abdeadbeef1234567890ab (rawhide-
build)"?

Still, it is the only way the rawhide-build branch can possibly be actually
used.


This is appropriate when the provenpackager needs the rebuild in a side
tag because other packages that depend on it also need to be rebuilt. This
still makes things harder for the maintainer who wants to fix the package,
but if the provenpackager really needs the new build, this gets them
there.  The history is still [l]inear


For some definition of "linear". It does indeed not introduce branching or
merging, but it does introduce a cumulative revert commit that makes the
history go backwards. I would say the history is indeed linear, but non-
monotonic.


(no force push anywhere)


The force push does not introduce non-linear history either. And doing a
hard reset and force push actually preserves not only the linearity, but
also the monotonicity of the history on the server.


But git is distributed, the server isn't the only copy of the history.

A force push breaks history. I can't believe we're even discussing
this point.


so the maintainer can still re-apply their changes (or revert the revert)
and then fix them.


The maintainer can also trivially re-apply their changes if the server
force-pushed them out of the way.

If your local history is:

ccc ← rawhide
  |
bbb ← origin/rawhide
  |
aaa

then you push this to the server:

ccc ← rawhide,

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

2021-02-08 Thread Kevin Fenzi

Is there really a need for a rawhide-build branch?

What if we just pushed a tag for the commit that built after the build
finishes in koji?

We already have this information in pagure... 

for example, look at 
https://src.fedoraproject.org/rpms/ansible/c/e89035e0fbd49cd2569dc923325e373bee43fbad

and see the:

Build completed
success
Built as ansible-2.9.17-3.fc34
13 days ago

with link to the build. 

kevin


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

Re: Orphaned packages looking for new maintainers


On 08. 02. 21 19:03, Gwyn Ciesla via devel wrote:

I believe Tomasz was asking about the many packages that indirectly require 
uw-imap.


Oh. Right, php indeed.

--
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: Orphaned packages looking for new maintainers

2021-02-08 Thread Gwyn Ciesla via devel

I believe Tomasz was asking about the many packages that indirectly require 
uw-imap.


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

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, February 8, 2021 11:58 AM, Miro Hrončok  wrote:

> On 08. 02. 21 17:08, Tomasz Torcz wrote:
> 

> > What's the magic deep dependency for uw-imap? Is it PHP?
> 

> uw-imap is orphaned directly. No magic.
> 

> It was orphaned due to https://bugzilla.redhat.com/show_bug.cgi?id=1907175
> 

> --
> 

> 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



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

Re: Orphaned packages looking for new maintainers


On 08. 02. 21 17:08, Tomasz Torcz wrote:


   What's the magic deep dependency for uw-imap? Is it PHP?


uw-imap is orphaned directly. No magic.

It was orphaned due to https://bugzilla.redhat.com/show_bug.cgi?id=1907175

--
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: [Qa-tools-sig] Orphaned packages looking for new maintainers

2021-02-08 Thread Frantisek Zatloukal

On Mon, Feb 8, 2021 at 4:57 PM Miro Hrončok  wrote:

> python-flask-openid  orphan, pjp, sundaram 0 weeks
> ago
>

Taken. We still need that for blockerbugs, sigh.

It's dead upstream, replaced by oidc. I'll try to poke others depending on
this (eg. copr) once we finish migration and retire it once completed.

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
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: Request for exception to non-responsive maintainer policy for Sugar packages

2021-02-08 Thread Peter Robinson

On Sun, Feb 7, 2021 at 6:28 PM Alex Perez  wrote:
>
> Hi folks,
>
>
>
> I've opened https://pagure.io/fesco/issue/2574 to facilitate assumption 
> ownership of the Sugar packages in Fedora, most of which are de-facto 
> abandoned by the previous maintainer, erikos, who has not authenticated with 
> his FAS account since March of 2017, nearly three years ago. I can't find a 
> working e-mail address for him, and @chimosky and I are trying to get the 
> remaining core Sugar packages updated to the current version, before the F34 
> freeze happens. Therefore, time is of the essence. The only two e-mail 
> addresses I could find for Simon were both aliases, si...@laptop.org and 
> si...@sugarlabs.org. Both are no longer functional, nor have they been for a 
> couple of years.
>
>
>
> As an aside, I'd like to propose that FESCO consider revising the 
> requirements to simplify/expedite assumption of packages which have clearly 
> been abandoned by their previous maintainers. Perhaps "has not authenticated 
> to FAS in 2+ years" could be considered a form of abandonment? This subject 
> seems worthy of discussion at the next FESCO meeting.
>
>  $ ./fedora_active_user.py --user erikos
>
> FAS username: aperezbios
> FAS password for aperezbios:
> Last login in FAS:
>erikos 2017-03-10
>
> Last action on koji:
>Sun, 06 Dec 2020 tag_package_owners entry revoked by oscar
>
> Last package update on bodhi:
>No activity found on bodhi

Yet you didn't reach out to a co-maintainer such as myself?
___
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: Orphaned packages looking for new maintainers

2021-02-08 Thread Adam Williamson

On Mon, 2021-02-08 at 17:00 +, José Abílio Matos wrote:
> On Monday, February 8, 2021 3:54:29 PM WET Miro Hrončok wrote:
> > python-blinker   orphan, pjp, sundaram 0 weeks
> > ago
> 
> I took python-blinker that is required by nikola. In particular it means that 
> the following users/groups are covered:

For the record it's also required by fedora-messaging, which is why
just about everything else in the world needed it :)
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

Re: Orphaned packages looking for new maintainers

2021-02-08 Thread José Abílio Matos

On Monday, February 8, 2021 3:54:29 PM WET Miro Hrončok wrote:
> python-blinker   orphan, pjp, sundaram 0 weeks
> ago

I took python-blinker that is required by nikola. In particular it means that 
the following users/groups are covered:

abompard: python-blinker
adamwill: python-blinker
adrian: python-blinker
bruno: python-blinker
cqi: python-blinker
devrim: python-blinker
firemanxbr: python-blinker
fivaldi: python-blinker
infra-sig: python-blinker
jamatos: python-blinker
jdornak: python-blinker
jkaluza: python-blinker
jsedlak: python-blinker
kparal: python-blinker
lsedlar: python-blinker
maxamillion: python-blinker
mrmeee: python-blinker
ngompa: python-blinker
pingou: python-blinker
qa-tools-sig: python-blinker
qwan: python-blinker
ralph: python-blinker
rkuska: python-blinker
rmarko: python-blinker
tjikkun: python-blinker

Regards,
-- 
José Abílio

___
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 34 Mass Branching

2021-02-08 Thread Mohan Boddu

Hello All,

Fedora 34 will be branched from rawhide on Feb 09th 2021 as per the
Fedora 34 schedule[1]. The process takes about a day and everything
should be ready by Feb 10th 2021. You can still be able to build
packages normally until then, but after the mass branching, rawhide
and F34 will be separated.

We will send another email once the branching is done.

Thanks,
Mohan Boddu.

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
___
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

Fedora 34 Mass Branching

2021-02-08 Thread Mohan Boddu

Hello All,

Fedora 34 will be branched from rawhide on Feb 09th 2021 as per the
Fedora 34 schedule[1]. The process takes about a day and everything
should be ready by Feb 10th 2021. You can still be able to build
packages normally until then, but after the mass branching, rawhide
and F34 will be separated.

We will send another email once the branching is done.

Thanks,
Mohan Boddu.

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20210208.n.0 changes

2021-02-08 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20210207.n.0
NEW: Fedora-Rawhide-20210208.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   95
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   4.66 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   610.99 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20210208.n.0.iso

= DROPPED IMAGES =
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20210207.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  CubicSDR-0.2.5-13.20200824git4f1db55.fc34
Old package:  CubicSDR-0.2.5-12.20200824git4f1db55.fc34
Summary:  Cross-Platform Software-Defined Radio Panadapter
RPMs: CubicSDR
Size: 5.56 MiB
Size change:  -163 B
Changelog:
  * Sun Feb 07 2021 Richard Shaw  - 
0.2.5-13.20200824git4f1db55
  - Rebuild for hamlib 4.1.


Package:  FAudio-21.02-1.fc34
Old package:  FAudio-21.01-1.fc34
Summary:  FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 
Refresh libraries
RPMs: libFAudio libFAudio-devel
Size: 828.43 KiB
Size change:  1.78 KiB
Changelog:
  * Sun Feb 07 2021 Michael Cronenworth  - 21.02-1
  - Update to 21.02


Package:  InsightToolkit-4.13.3-4.fc34
Old package:  InsightToolkit-4.13.3-3.fc34
Summary:  Insight Toolkit library for medical image processing
RPMs: InsightToolkit InsightToolkit-devel InsightToolkit-doc 
InsightToolkit-examples InsightToolkit-vtk InsightToolkit-vtk-devel
Size: 76.99 MiB
Size change:  -9.88 KiB
Changelog:
  * Sun Jan 31 2021 Orion Poplawski  - 4.13.3-4
  - Rebuild for VTK 9


Package:  NetworkManager-l2tp-1.8.6-5.fc34
Old package:  NetworkManager-l2tp-1.8.6-3.fc34
Summary:  NetworkManager VPN plugin for L2TP and L2TP/IPsec
RPMs: NetworkManager-l2tp NetworkManager-l2tp-gnome
Size: 1.14 MiB
Size change:  -22 B
Changelog:
  * Sun Feb 07 2021 Douglas Kosovic  - 1.8.6-4
  - Sync with EPEL8

  * Sun Feb 07 2021 Douglas Kosovic  - 1.8.6-5
  - Correct EPEL8 conditional


Package:  YafaRay-3.5.1-7.fc34
Old package:  YafaRay-3.5.1-6.fc34
Summary:  A free open-source ray-tracing render engine
RPMs: YafaRay YafaRay-blender YafaRay-devel YafaRay-lib python3-YafaRay
Size: 4.49 MiB
Size change:  -1.93 KiB
Changelog:
  * Sun Feb 07 2021 Luya Tshimbalanga  - 3.5.1-7
  - Update url for upstream new github repository
  - Update renamed sources from upstream


Package:  awesome-4.3-9.fc34
Old package:  awesome-4.3-8.fc34
Summary:  Highly configurable, framework window manager for X. Fast, light 
and extensible
RPMs: awesome awesome-doc
Size: 5.07 MiB
Size change:  -623 B
Changelog:
  * Sat Feb 06 2021 Xaver Hellauer  ??? 4.3-9
  - vi as weak dependency


Package:  blender-1:2.91.2-4.fc34
Old package:  blender-1:2.91.2-1.fc34
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-rpm-macros
Size: 123.70 MiB
Size change:  -813.61 KiB
Changelog:
  * Sun Jan 24 2021 Luya Tshimbalanga  - 1:2.91.2-2
  - Rebuild for opensubdiv with enabled ptex

  * Tue Jan 26 2021 Fedora Release Engineering  - 
1:2.91.2-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sun Feb 07 2021 Luya Tshimbalanga  - 1:2.91.2-4
  - Rebuild for oidn 1.3.0


Package:  cmake-3.19.4-2.fc34
Old package:  cmake-3.19.4-1.fc34
Summary:  Cross-platform make system
RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui 
cmake-rpm-macros
Size: 46.10 MiB
Size change:  5.67 KiB
Changelog:
  * Sat Feb 06 2021 Rex Dieter  - 3.19.4-2
  - CMake warning when searching for Boost 1.75 (#1925355)


Package:  coolreader-3.2.53-1.fc34
Old package:  coolreader-3.2.51-2.fc34
Summary:  Cross platform open source e-book reader
RPMs: coolreader
Size: 12.13 MiB
Size change:  74.67 KiB
Changelog:
  * Sun Feb 07 2021 Andy Mender  - 3.2.53-1
  - Update to version 3.2.53


Package:  csmith-2.4.0-1.fc34
Old package:  csmith-2.3.0-6.fc34
Summary:  Tool to generate random C programs for compiler testing
RPMs: csmith csmith-devel
Size: 2.33 MiB
Size change:  231.36 KiB
Changelog:
  * Sun Feb 07 2021 Robin Lee  - 2.4.0-1
  - Update 2.4.0 (RHBZ#1925715)


Package:  elfutils-0.183-1.fc34
Old package:  elfutils-0.182-3.fc34
Summary:  A collection of utilities and DSOs to handle ELF files and DWARF 
data
RPMs: elfutils elfutils-debuginfod elfutils-debuginfod-client 
elfutils-debuginfod-client-devel elfutils-default-yama-scope elfutils-devel 
elfutils-libelf elfutils-libelf-devel elfutils-libs
Size: 6.65 MiB
Size change:  57.21 KiB
Changelog

Re: Orphaned packages looking for new maintainers

2021-02-08 Thread Tomasz Torcz


  What's the magic deep dependency for uw-imap? Is it PHP?

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

2021-02-08 Thread Kalev Lember



On 2/6/21 18:06, Florian Weimer wrote:

* Kalev Lember:


On 2/6/21 16:08, Antonio T. sagitter wrote:

Hi all.
I can't compile IceCat on Fedora 33+ since some days because of
these errors:
...
/usr/include/c++/11/type_traits:3164:1: error: template with C linkage
..
Any idea why they occur?
Rawhide build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=61460307


This looks like fallout from
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1715 (I don't know
if it's icecat doing something wrong or it's something that glib is
doing wrong).


Icecat is probably including the glib header in an extern "C" block.
You can escape from that by including  inside an extern
"C++" block.  See /usr/include/math.h for an example.


Thanks! I went ahead and filed 
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1935 with the 
suggested change.


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

Orphaned packages looking for new maintainers


The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-02-08.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

 Package   (co)maintainers Status Change

apache-log4j-extras  coolsvap, gil, orphan 6 weeks ago
auto-destdir orphan5 weeks ago
azureus  orphan6 weeks ago
cliveorphan5 weeks ago
csync2   asalkeld, orphan, simonp  4 weeks ago
eclipse-cdt  akurtakov, eclipse-sig, jjohnstn, 2 weeks ago
 kdaniel, orphan, rgrunber
eclipse-pydeveclipse-sig, jjohnstn, orphan 1 weeks ago
eclipse-remote   eclipse-sig, orphan   3 weeks ago
felix-bundlerepository   mizdebsk, orphan  0 weeks ago
freemarker   orphan3 weeks ago
geronimo-jcdi-1.1-apiorphan0 weeks ago
geronimo-validation  orphan0 weeks ago
git-up   orphan0 weeks ago
gnatcoll-db  landgraf, orphan  0 weeks ago
golang-gvisoreclipseo, elmarco, orphan 1 weeks ago
jabberpy orphan4 weeks ago
jnr-enxiojjohnstn, orphan, rgrunber3 weeks ago
jnr-unixsocket   jjohnstn, orphan, rgrunber3 weeks ago
jython   akurtakov, dmalcolm, jmatthews,   1 weeks ago
 lkundrak, orphan, pmackinn
lcm  dcallagh, mrunge, nmarques, orphan1 weeks ago
libmypaint2  orphan3 weeks ago
lzma-sdk orphan0 weeks ago
nagios   nb, orphan, smooge, swilkerson0 weeks ago
nagios-plugins   nb, orphan, smooge, swilkerson0 weeks ago
nettymizdebsk, orphan  1 weeks ago
nim  orphan4 weeks ago
nodejs-shelljs   nodejs-sig, orphan, patches   6 weeks ago
nodoka-theme-gnome   orphan6 weeks ago
nrpe hedenface, nb, orphan, smooge,0 weeks ago
 swilkerson
ocaml-merlin orphan0 weeks ago
ocaml-ocp-indent orphan0 weeks ago
os-maven-plugin  mizdebsk, orphan  1 weeks ago
pidgin-logviewer orphan0 weeks ago
pipx orphan0 weeks ago
puppetlabs-stdlibgchamoul, orphan  1 weeks ago
python-XStatic-jquery-ui mrunge, openstack-sig, orphan 3 weeks ago
python-blinker   orphan, pjp, sundaram 0 weeks ago
python-couchbase orphan4 weeks ago
python-django-annoying   orphan0 weeks ago
python-django-registration   orphan0 weeks ago
python-flask-assets  orphan, pjp, sundaram 0 weeks ago
python-flask-oauth   orphan, pjp, sundaram 0 weeks ago
python-flask-openid  orphan, pjp, sundaram 0 weeks ago
python-kyotocabinet  orphan4 weeks ago
python-requests-credssp  orphan4 weeks ago
python-ryu   apevec, orphan, slaweq3 weeks ago
python-setuptools_hg orphan

Re: Continuously trim SWAP in Fedora guest over virtio-scsi controller

2021-02-08 Thread Richard W.M. Jones

On Sat, Feb 06, 2021 at 04:11:46PM +0100, Pavel Raiskup wrote:
> I'm trying to overcommit storage space on one our hypervisors (and reclaim
> space if possible after memory peak times) and it seems like kernel in
> Fedora 33 isn't doing automatic discard on swap partitions?  The swap is
> enabled by:
> 
>   $ swapon --discard /dev/sda
> 
> The guest (on RHEL 8 HV host) is started with virtio-scsi controller to
> propagate the trim requests to the host storage, the volumes I tried were
> both of raw and qcow2 format.
> 
> The 'fstrim -av' isn't propagated to SWAP mount points (expected
> probably).  The only thing that helps to shrink the host volume allocated
> for guest swap is 'swapoff -a && swapon --discard /dev/sda' (but I assume
> TRIM is sent to the driver in this case, and that the problem isn't in the
> host libvirt setup).

fstrim will only trim a regular filesystem.  AFAIK swap is not
involved in any way when you do fstrim.  On the other hand swapon --discard
is correct, but you may need to check that --discard=pages was
selected.  I have no idea what particular operations will cause a TRIM
to actually be sent though - it could also depend on the kernel
version.  It seems unlikely that the kernel would send TRIM for every
single freed page because that would be very expensive on some
devices.

If you want to monitor what requests are seen on the hypervisor side,
I'd suggest running this command on the hypervisor:

  nbdkit memory 10G --filter=log logfile=/var/tmp/log

Modify the guest's libvirt XML (virsh edit guestname) to add:

  


  


  

(You might have to open port 10809 on the firewall, or else use
a Unix domain socket)

Then put the swap on /dev/sdb in the guest.

Then do whatever experiments you need and you should see (or perhaps
not see) Trim requests in /var/tmp/log.

You might nee dto play with  setting
in the libvirt XML too.  I can't remember if that's the default or
not.

Rich.

> But otherwise, freeing the guest memory manually, minimizing the swap usage,
> etc. (experiments with tmpfs) doesn't result in freeing the allocated storage
> blocks on host.
> 
> Am I doing something wrong, is this expected or is this a bug?
> 
> FTR, I tested "kernel-core-5.10.11-200.fc33.x86_64" and
> "kernel-core-5.10.12-200.fc33.x86_64" but this is not a regression -- I'm
> experimenting with TRIM in this setup for the first time.
> 
> Dmesg output seems to indicate page cluster trim is enabled (c symbol):
> [ 3936.914260] Adding 33554428k swap on /dev/sda.  Priority:-2 extents:1 
> across:33554428k DscFS
> 
> Thanks,
> Pavel
> 
> 
> ___
> 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

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

Orphaned packages looking for new maintainers


The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-02-08.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

 Package   (co)maintainers Status Change

apache-log4j-extras  coolsvap, gil, orphan 6 weeks ago
auto-destdir orphan5 weeks ago
azureus  orphan6 weeks ago
cliveorphan5 weeks ago
csync2   asalkeld, orphan, simonp  4 weeks ago
eclipse-cdt  akurtakov, eclipse-sig, jjohnstn, 2 weeks ago
 kdaniel, orphan, rgrunber
eclipse-pydeveclipse-sig, jjohnstn, orphan 1 weeks ago
eclipse-remote   eclipse-sig, orphan   3 weeks ago
felix-bundlerepository   mizdebsk, orphan  0 weeks ago
freemarker   orphan3 weeks ago
geronimo-jcdi-1.1-apiorphan0 weeks ago
geronimo-validation  orphan0 weeks ago
git-up   orphan0 weeks ago
gnatcoll-db  landgraf, orphan  0 weeks ago
golang-gvisoreclipseo, elmarco, orphan 1 weeks ago
jabberpy orphan4 weeks ago
jnr-enxiojjohnstn, orphan, rgrunber3 weeks ago
jnr-unixsocket   jjohnstn, orphan, rgrunber3 weeks ago
jython   akurtakov, dmalcolm, jmatthews,   1 weeks ago
 lkundrak, orphan, pmackinn
lcm  dcallagh, mrunge, nmarques, orphan1 weeks ago
libmypaint2  orphan3 weeks ago
lzma-sdk orphan0 weeks ago
nagios   nb, orphan, smooge, swilkerson0 weeks ago
nagios-plugins   nb, orphan, smooge, swilkerson0 weeks ago
nettymizdebsk, orphan  1 weeks ago
nim  orphan4 weeks ago
nodejs-shelljs   nodejs-sig, orphan, patches   6 weeks ago
nodoka-theme-gnome   orphan6 weeks ago
nrpe hedenface, nb, orphan, smooge,0 weeks ago
 swilkerson
ocaml-merlin orphan0 weeks ago
ocaml-ocp-indent orphan0 weeks ago
os-maven-plugin  mizdebsk, orphan  1 weeks ago
pidgin-logviewer orphan0 weeks ago
pipx orphan0 weeks ago
puppetlabs-stdlibgchamoul, orphan  1 weeks ago
python-XStatic-jquery-ui mrunge, openstack-sig, orphan 3 weeks ago
python-blinker   orphan, pjp, sundaram 0 weeks ago
python-couchbase orphan4 weeks ago
python-django-annoying   orphan0 weeks ago
python-django-registration   orphan0 weeks ago
python-flask-assets  orphan, pjp, sundaram 0 weeks ago
python-flask-oauth   orphan, pjp, sundaram 0 weeks ago
python-flask-openid  orphan, pjp, sundaram 0 weeks ago
python-kyotocabinet  orphan4 weeks ago
python-requests-credssp  orphan4 weeks ago
python-ryu   apevec, orphan, slaweq3 weeks ago
python-setuptools_hg orphan

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Jonathan Wakely wrote:
> You've completely misunderstood the suggestion.

No, sorry, I understood it completely. I think that you are the one who 
completely misunderstood my objection, and also missed the point of the 
original post. Let me explain:

> I'm suggesting that everybody pushes to rawhide just like today.
> Maintainers and provenpackagers. Nothing changes in that respect. There is
> a read-only branch called rawhide-build which contains the
> last-known-to-build commit from rawhide. Nobody can push to rawhide-build,
> it only gets updated automatically when a build completes in koji.

Yes, I got that.

But how does that address the point of the OP that provenpackagers need the 
rawhide branch to be buildable so they can *automatically* bump and commit 
to it?

Let's say that I am a provenpackager (which I happen to actually be) and 
that I want to do a scripted mass-rebuild (which is unlikely to happen in my 
case, but other provenpackagers have that need, so let's please assume it). 
What value does a read-only rawhide-build branch give me? It just tells me 
what was the last commit that built, an information I can just get directly 
from Koji. Having this in git does not help me in any way.

> If a maintainer wants to fix the broken state they created, they just
> fix it locally and push. There's no need to reset or merge in the
> revert that happened upstream (because that would be extra work for
> them, and non-trivial to do right for devs who aren't comfortable with
> Git beyond the basics).

And that is exactly the same as the status quo, no rawhide-build branch 
needed.

> If a provenpackager needs to bump and rebuild they have choices (but
> none of them involve touching rawhide-build as that's read-only):

So who needs rawhide-build then?

> 1) Do nothing. The package is broken anyway. The maintainer needs to
> fix it anyway. It will be rebuilt after they fix it. Why should the
> provenpackager fix it? Often they don't need to. This is less work for
> the provenpackager, and leaves the rawhide branch in the state where
> the maintainer last touched it, so they can easily start fixing it.

That's what the OP explicitly does not want to do. It happens now for lack 
of a better solution, but it means that packages that need to be rebuilt for 
a broken dependency will be stuck with the broken dependency.

> 2) Proven packager *manually* does git revert for the commits that are
> on rawhide but not rawhide-build (which is an easy way to know which
> commits were added since the last successful build)

The whole point of this thread is that doing this manually does not scale to 
a scripted mass rebuild.

And there is indeed no way to automate the general case where there can be 
not only more than one commit in a linear history, but also merge commits 
making the history non-linear. The only effective way (hard reset and force 
push) is banned by our Git hooks.

> Or soft reset to rawhide-build and commit.

That could work, even automatically, but it breaks the history by 
introducing an SVN-style "merge commit" that is not really a git merge or a 
git revert, but masquerades as a plain commit. And what should the commit 
message be? "Revert to deadbeef1234567890abdeadbeef1234567890ab (rawhide-
build)"?

Still, it is the only way the rawhide-build branch can possibly be actually 
used.

> This is appropriate when the provenpackager needs the rebuild in a side
> tag because other packages that depend on it also need to be rebuilt. This
> still makes things harder for the maintainer who wants to fix the package,
> but if the provenpackager really needs the new build, this gets them
> there.  The history is still [l]inear

For some definition of "linear". It does indeed not introduce branching or 
merging, but it does introduce a cumulative revert commit that makes the 
history go backwards. I would say the history is indeed linear, but non-
monotonic.

> (no force push anywhere)

The force push does not introduce non-linear history either. And doing a 
hard reset and force push actually preserves not only the linearity, but 
also the monotonicity of the history on the server.

> so the maintainer can still re-apply their changes (or revert the revert)
> and then fix them.

The maintainer can also trivially re-apply their changes if the server 
force-pushed them out of the way.

If your local history is:

ccc ← rawhide
   |
bbb ← origin/rawhide
   |
aaa

then you push this to the server:

ccc ← rawhide, origin/rawhide
   |
bbb
   |
aaa

and then the server does the force push:

ccc ← rawhide, apparent origin/rawhide
   |
bbb ← actual origin/rawhide
   |
aaa

then you fix the build:

ddd ← rawhide
   |
ccc ← apparent origin/rawhide
   |
bbb ← actual origin/rawhide
   |
aaa

and then you push rawhide, git will actually NOT complain, and this is NOT a 
force-push, but a standard fast-forward push. bbb is an ancestor of 
ddd, so the

Re: Update on Modular Obsoletes and EOL change

2021-02-08 Thread Matthew Miller

On Mon, Feb 08, 2021 at 04:09:19PM +0100, Martin Curlej wrote:
> It would be great if we could start a discussion about how modular
> obsoletes will be used in Fedora? Where will be they stored? Who will be
> able to change them? Just a couple of questions to get the discussion
> started. Any involvement of the Fedora community is highly appreciated.

On EOL, not specifically Obsoletes, but since they're deeply related:

In general, the idea is that in Fedora context, modules are most useful when
they're longer-lived than the normal 13-month release cycle (rather than the
RHEL case of being shorter than 10 years). I suggest therefore:

1. Module EOL should always align with a Fedora Linux release EOL (i.e.
   May/November every year). That way, people aren't ending up with modules
   randomly ending at unpredictable times.

2. If an upstream is ending at an unaligned time, Module owners should plan
   to separately deal with any critical security issues for another couple
   of months, or EOL the module at the _sooner_ date.

3. If an upstream is something that changes faster than the Fedora Linux
   release cycle (shorter than 13 months), the module stream should be
   rolling rather than pinned to those short-lived versions.

-- 
Matthew Miller

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

Re: Update on Modular Obsoletes and EOL change


On 08. 02. 21 16:09, Martin Curlej wrote:
It would be great if we could start a discussion about how modular obsoletes 
will be used in Fedora? Where will be they stored? Who will be able to change 
them? Just a couple of questions to get the discussion started. Any involvement 
of the Fedora community is highly appreciated.


IIRC the consensus in 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IVI6KR6MDXGOKFM3LEGNIMISRVBW5BBQ/ 
was that they will be stored in dist git and the module maintainers will be able 
to change them.


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

Update on Modular Obsoletes and EOL change

2021-02-08 Thread Martin Curlej

Hello All,

This is an update about the Module obsoletes and EOL [1] change which we
proposed for F34. We have a little bit of a good news/bad news situation
here.

The good news is that the groundwork for the Obsoletes and EOL has been
done. DNF, libmodulemd and createrepo_c accept the format and know how to
work with it. All the technical changes are submitted (we are working on
documentation right now [2]), merged and can be tried out in rawhide. The
format definition for the obsoletes can be found here [3].

The bad news is that we are not able to add the support of the obsolete
format to the Fedora pipeline for F34. So we are postponing it to F35 for
now.

The one thing that we need to discuss, before making changes to the Fedora
pipeline, is how the obsoletes will be used in Fedora. As the
obsoletes/lifecycles enable you to set lifecycles which are not bound to
the release cycle of a Fedora release. The Modularity team mostly cares
about the standards of the technology (i. e. what are the file formats, how
modules are built etc.) were not here to set/mandate the policies of
metadata distribution in a release pipeline.

It would be great if we could start a discussion about how modular
obsoletes will be used in Fedora? Where will be they stored? Who will be
able to change them? Just a couple of questions to get the discussion
started. Any involvement of the Fedora community is highly appreciated.

[1] https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL
[2] https://github.com/rpm-software-management/dnf/pull/1717
[3]
https://github.com/fedora-modularity/libmodulemd/blob/main/yaml_specs/modulemd_obsoletes_v1.yaml

Martin Curlej

Software Engineer, Product Owner

Modularity

Red Hat

mcur...@redhat.com

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

Re: Fedora 34 Mass Rebuild

2021-02-08 Thread Milan Crha

On Mon, 2021-02-01 at 15:03 -0500, Mohan Boddu wrote:
> Fedora 34 mass rebuild of rpms is done

Hi,
I just noticed that syncevolution built just fine on the January 30th,
but it is failing to build right now, using the same sources as releng.
I opened [1] for it.

It kind of scares me, I do not know how to decipher it. Is it that the
mass rebuild was not done against proper packages?
Bye,
Milan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1926239
___
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 2021-02-05 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/05/report-389-ds-base-2.0.2-20210205gitf38b124f0.fc33.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

[389-devel] 389 DS nightly 2021-02-03 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/03/report-389-ds-base-2.0.2-20210203gitf38b124f0.fc33.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

[389-devel] 389 DS nightly 2021-02-08 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/08/report-389-ds-base-2.0.2-20210208gitf38b124f0.fc33.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

[389-devel] 389 DS nightly 2021-02-07 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/07/report-389-ds-base-2.0.2-20210207gitf38b124f0.fc33.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

[389-devel] 389 DS nightly 2021-02-04 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/04/report-389-ds-base-2.0.2-20210204gitf38b124f0.fc33.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

Copr/mock centos-stream => centos-stream-8 rename?

2021-02-08 Thread Pavel Raiskup

The configuration for CentOS Stream 8 was renamed in mock-core-configs so
it makes more sense now (currently the updated package is getting to
updates-testing), and we'll have to adjust Fedora Copr to comply with
that layout.

The idea now is to try script the movement on backend (built results), and
create compat symlink 'centos-stream-x86_64 => centos-stream-8-x86_64'.
This way new build results will be put into the new location, and old
clients will be able to access old/new results.

Does this make sense, or is there a better idea?

From the UI/API perspective, I believe we'll be able to migrate the
existing chroot transparently without disabling old one and creating a new
one.  If this doesn't happen to be possible (new chroot will be needed)
I'll reply here to warn you that the centos-stream buildroot needs to be
re-enabled.  In any case, note that the `--chroot centos-stream-x86_64`
option will stop working very soon, and you should start using
`--chroot centos-stream-8-x86_64`.

Pavel


___
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 Change: fbrnch (Self-Contained Change proposal)

2021-02-08 Thread Jens-Ulrik Petersen

On Wed, Jan 20, 2021 at 11:31 PM Jens-Ulrik Petersen 
wrote:

> On Tue, Jan 19, 2021 at 1:38 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> > ** Submit and complete package review(s).
>>
>
I still need one more package review completed before I can build fbrnch in
Rawhide and submit it's review:

ghc-pretty-terminal (NEW)
https://bugzilla.redhat.com/show_bug.cgi?id=1925891
If anyone can help review it, that would be great.

Thanks, Jens
___
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-08 Thread Stephen John Smoogen

On Sun, 7 Feb 2021 at 18:26, Kevin Fenzi  wrote:

> Overall this seems fine to me, a few nitpicks inline...
>
> On Fri, Feb 05, 2021 at 01:51:15PM -0800, Troy Dawson wrote:
> > This is a proposal.  It's mainly writing down what I think most of us
> > agreed on at last weeks EPEL Steering Committee meeting.  Feel free to
> > continue to discuss and/or have ideas.
> > I've been asked by a couple places what the plans were, so I'm writing
> it here.
> >
> > Overall Plan:
> > - epel-next is an epel branch that is built against CentOS Stream.
> epel-next
> > only has the packages that would be incompatible with released RHEL
> > builds, or if an EPEL maintainer is updating a package that will only
> > be released to regular EPEL at the next RHEL release.
> > - We plan on creating epel9-next when CentOS 9 Stream has a public
> > repository.  We plan on using the EPEL Packaging SIG to populate it
> > early with common packages, although any EPEL package maintainers can
> > add their packages whenever they want.
>
> This part I am unsure of. What are 'common packages' ?
> We should make sure and ask maintainers to branch and maintain packages
> they want for this, but I think it would be odd to just do it without
> them being in the loop. We never never 'mass branched' things in the
> past. EPEL isn't a specific set of packages, it's packages maintainers
> want to maintain. That said, if there's packages of interest where the
> maintainers are not interested in epel, the epel sig should definitely
> branch and maintain those.
>
>
There is a little nuance here. In order to get the repository going, we had
to 'mass-branch' about 40 or so packages. fedpkg and some other items
require quite a few packages which all have to be done at once. Without
those you can't build anything else to put into EPEL... so I would say that
EPEL is the specific set of packages in order to get a minimal repository
working in the Fedora Build System. Everything else is just extras people
add to it.



> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>


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

License field change: wdiff (“GPLv3+” to “GPLv3+ and Latex2e”)

2021-02-08 Thread Benjamin Beasley

The License field for wdiff has been corrected from “GPLv3+” to “GPLv3+ and 
Latex2e”; the latter applies to the texinfo documentation.
___
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 1926184] New: bugzilla-5.0.6-11.fc34 FTBFS: Can't exec "make": No such file or directory at docs/makedocs.pl line 56.

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

Bug ID: 1926184
   Summary: bugzilla-5.0.6-11.fc34 FTBFS: Can't exec "make": No
such file or directory at docs/makedocs.pl line 56.
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/bugzilla?col
lection=f34
Status: NEW
 Component: bugzilla
  Assignee: ita...@ispbrasil.com.br
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, ita...@ispbrasil.com.br,
perl-devel@lists.fedoraproject.org
Blocks: 1868278 (F34FTBFS)
  Target Milestone: ---
Classification: Fedora



bugzilla-5.0.6-11.fc34 fails to build in Fedora 34:

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.DaBHvL
+ umask 022
+ cd /builddir/build/BUILD
+ cd bugzilla-release-5.0.6
+ docs/makedocs.pl --with-pdf
Creating API documentation...
Creating HTML documentation ...
Can't exec "make": No such file or directory at docs/makedocs.pl line 56.
Creating TXT documentation ...
Can't exec "make": No such file or directory at docs/makedocs.pl line 56.
Creating PDF documentation ...
Can't exec "make": No such file or directory at docs/makedocs.pl line 56.
Error occurred building the documentation
error: Bad exit status from /var/tmp/rpm-tmp.DaBHvL (%build)

A difference between passing and failing build root is at
. This is probably triggered
by removing "make" packages from a minimal build root.

docs/makedocs.pl indeed executes make:

  say "Creating $name documentation ..." if defined $name;
→ system('make', $cmdline) == 0 or $error_found = 1;
  print "\n";

I propose to add "BuildRequires: make" into "for building docs" section in a
spec file.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1868278
[Bug 1868278] (F34FTBFS) - Fedora 34 FTBFS Tracker
-- 
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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git


On 04/02/21 05:03 +0100, Kevin Kofler via devel wrote:

Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote:

But it means that provenpackagers who want to bump and rebuild have to
actually manually look at another branch (rawhide-build).


No, why would they need to do that?


Because the whole point of the thread is that they need to bump and rebuild
from a state that already builds. Otherwise, why would we add the CI to
begin with?


The question aside, they wouldn't be allowed to do that, anyway.


Surely they would be allowed to LOOK at the branch, and hopefully also to
check it out (read only), otherwise why create that branch to begin with?


The idea is that only CI can push there once there's a successful build
from rawhide branch.


And that is exactly what makes the whole idea worthless. Provenpackagers
need to bump the branch that actually builds and then push that to rawhide.


Not always. Sometimes if a package is already broken in rawhide, then
I'm quite happy to just skip it during my rebuilds.



This only works in a useful way if the branch that actually builds IS
rawhide.


Plus, they will then need to revert rawhide to rawhide-build,


Again, why?


Because, by definition, rawhide-build compiles and rawhide might not.


And the rawhide-build ref tells you the last state that builds, so you
can easily compare it to rawhide. It could be just a tag that gets
moved with git tag -f every time there is a successful build, but I
think a branch ref might be simpler (it's no more overhead in Git, and
doesn't depend on --no-tags or branch.rawhide.tagOpt).

I'm not suggesting a solution to "provenpackagers need to build things
that might be broken". But I don't think automatically
reverting/resetting the repo after a failed build is a good solution
to that either, and it has provable problems (rewriting history with
resets and force pushes will definitely cause friction and problems
for maintainers).

What I'm suggesting is non-destructive, but gives us an easy way to
find the last-known-good commit in dist-git. Your suggestion is
destructive and doesn't give us that. If I do a git fetch *while a
build is ongoing* I don't know if it's broken or not, I have to wait
for the build (which I might not even know is happening). So I might
fetch+bump+rebuild and it still fails, and then I have to fetch and
discover history has been rewritten, and reset, and try again. And
maybe that's still racing with an attempt to fix it from the
maintainer, so it fails again, and history gets rewritten again.

With a rawhide-build ref (whether branch or tag) I can use a single
git command to tell that rawhide is ahead of rawhide-build, and I
immediately know that either there is a built happening now, or
rawhide is broken. At that point I can decide whether I want to try
and fix it, or contact the maintainer, or wait.

Maybe "rawhide-good" or "rawhide-built" would be a better name for the
ref than "rawhide-build".

___
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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git


On 03/02/21 14:29 +0100, Kevin Kofler via devel wrote:

Jonathan Wakely wrote:

Instead of force pushing or reverting anything in the rawhide branch,
why not just have two branches?

Maintainers commit to one branch, and if the build is successful that
branch is automatically merged (as a fast-forward merge) to a
"rawhide-build" branch.

That way you know that what's on the rawhide-build branch was able to
successfully build (at one time ... it might fail later due to changes
to other packages).

That avoids any automated (and possibly error prone) resets or reverts
on the branch that the maintainer pushed to.


But it means that provenpackagers who want to bump and rebuild have to
actually manually look at another branch (rawhide-build). Plus, they will


No.


then need to revert rawhide to rawhide-build, which is not easily automated


No.


(and they cannot just reset and force-push, which would be the easy way,
because the git hooks prevent that). So, compared to my proposal, your
proposal pushes work away from automated infrastructure to packagers
(breaking their mass rebuild scripts, which is the whole point of this
thread), and makes it impossible to use force pushes (or at least
impractical: how should the exception in the git hooks be implemented?
Whereas exempting pushes submitted by the CI infrastructure would be
straightforward).

Hence, I cannot see how your suggestion would be an improvement over mine.


You've completely misunderstood the suggestion. I'm suggesting that
everybody pushes to rawhide just like today. Maintainers and
provenpackagers. Nothing changes in that respect. There is a read-only
branch called rawhide-build which contains the last-known-to-build
commit from rawhide. Nobody can push to rawhide-build, it only gets
updated automatically when a build completes in koji.

If a maintainer wants to fix the broken state they created, they just
fix it locally and push. There's no need to reset or merge in the
revert that happened upstream (because that would be extra work for
them, and non-trivial to do right for devs who aren't comfortable with
Git beyond the basics).

If a provenpackager needs to bump and rebuild they have choices (but
none of them involve touching rawhide-build as that's read-only):

1) Do nothing. The package is broken anyway. The maintainer needs to
fix it anyway. It will be rebuilt after they fix it. Why should the
provenpackager fix it? Often they don't need to. This is less work for
the provenpackager, and leaves the rawhide branch in the state where
the maintainer last touched it, so they can easily start fixing it.

2) Proven packager *manually* does git revert for the commits that are
on rawhide but not rawhide-build (which is an easy way to know which
commits were added since the last successful build). Or soft reset to
rawhide-build and commit. This is appropriate when the provenpackager
needs the rebuild in a side tag because other packages that depend on
it also need to be rebuilt. This still makes things harder for the
maintainer who wants to fix the package, but if the provenpackager
really needs the new build, this gets them there.  The history is
still inear (no force push anywhere) so the maintainer can still
re-apply their changes (or revert the revert) and then fix them.

Sometimes option 1) will be appropriate, sometimes option 2). Making
the reset/revert automatic doesn't give anybody a choice. Both options
ensure a linear history, no rewriting with force push.

I'm very strongly opposed to having automated force-pushes on the
rawhide branch to reset it to an earlier state. That doesn't just hurt
the maintainer who pushed the broken work, but anybody (including
provenpackagers) who fetched it before the history is altered.

I'm opposed to automated 'git revert' on rawhide (but not as strongly
as force pushing to public branches).

___
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 1925899] perl-JavaScript-Minifier-XS-0.14 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-JavaScript-Minifier-XS
   ||-0.14-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2021-02-08 11:25:38




-- 
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: New memory tester application potentially to replace memtest86+: PCMemTest

2021-02-08 Thread Vít Ondruch

Being devils advocate, but should we have the memtest86 or similar by 
default? I have certainly not used this feature in my 10+ yeas with Fedora.



Vít



Dne 07. 02. 21 v 10:07 Neal Gompa napsal(a):

Hey all,

I discovered today that there's a new replacement for memtest86+ that
appears to even have UEFI support called PCMemTest[0].

The main reason I call out to this is because we don't have a memory
tester offering in our UEFI boot variant for the Fedora live media,
and this is actively maintained (unlike memtest86+, which we currently
use...).

Mageia is shipping this starting with Mageia 8[1], and we should
consider shipping this with Fedora 34.

[0]: https://github.com/martinwhitaker/pcmemtest
[1]: https://wiki.mageia.org/en/Mageia_8_Release_Notes#PCMemTest

--
真実はいつも一つ！/ 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




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

Fedora-Cloud-32-20210208.0 compose check report

No missing expected images.

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

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

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

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

[Bug 1922738] perl-CSS-Minifier-XS-0.13 is available

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-CSS-Minifier-XS-0.13-1
   ||.fc34
 Resolution|--- |RAWHIDE
Last Closed||2021-02-08 08:28:07



--- Comment #2 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1704472


-- 
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 1925797] perl-Mojolicious-8.73 is available

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-8.73-1.fc3
   ||4
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-02-08 08:26:42



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1704479


-- 
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 1922738] perl-CSS-Minifier-XS-0.13 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1922738
Bug 1922738 depends on bug 1922774, which changed state.

Bug 1922774 Summary: Review Request: perl-Test-DiagINC - List modules and 
versions loaded if tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1922774

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE




-- 
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 1925899] perl-JavaScript-Minifier-XS-0.14 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|mmasl...@redhat.com |
   Doc Type|--- |If docs needed, set a value




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

[Bug 1925837] perl-Log-Log4perl-1.54 is available