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

2021-02-07 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1925837

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jose.p.oliveira.oss@gmail.c |
   |om, ka...@ucw.cz,   |
   |st...@silug.org |
   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


Fedora-Cloud-33-20210208.0 compose check report

2021-02-07 Thread Fedora compose checker
No missing expected images.

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

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

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

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


Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

2021-02-07 Thread Jens Petersen
I added a `master-rename` command to fbrnch too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

2021-02-07 Thread Jens Petersen
> On Fri, Feb 05, 2021 at 03:35:27PM +0100, Vít Ondruch wrote:
> The issue being that if one of the step fails in one of your clones, the 
> entire
> loop will stop and won't run another time :/

I wrote a little tool called `lsfrom` for restarting such scripting. :-)

https://hackage.haskell.org/package/lsfrom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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] Fedora EPEL 7 updates-testing report

2021-02-07 Thread updates
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  52  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599   
openjpeg2-2.3.1-10.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e30a25d6d0   
chromium-88.0.4324.96-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4e3398c399   
libssh-0.7.7-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c09d7045f3   
seamonkey-2.53.6-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ba217a684f   
monitorix-3.13.1-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5ecfbfc6f6   
pngcheck-2.4.0-7.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6eebad70ee   
SDL2-2.0.14-2.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

openelp-0.9.2-1.el7

Details about builds:



 openelp-0.9.2-1.el7 (FEDORA-EPEL-2021-380682c3f0)
 Open Source EchoLink Proxy

Update Information:

Update to OpenELP 0.9.2

ChangeLog:

* Sun Feb  7 2021 Scott K Logan  - 0.9.2-1
- Update to 0.9.2 (rhbz#1925917)

References:

  [ 1 ] Bug #1925917 - openelp-0.9.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1925917


___
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


[EPEL-devel] Fedora EPEL 8 updates-testing report

2021-02-07 Thread updates
The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b68969af8c   
chromium-88.0.4324.96-1.el8
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-403074b7e0   
seamonkey-2.53.6-1.el8
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-aadbebf090   
monitorix-3.13.1-1.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-eca913b42e   
pngcheck-2.4.0-7.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-69b5865b58   
privoxy-3.0.31-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5e4b80b9d8   
zeromq-4.3.4-2.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1917130359   
czmq-4.2.1-2.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

NetworkManager-l2tp-1.8.6-5.el8
darktable-3.4.1-1.el8
openelp-0.9.2-1.el8
stress-ng-0.12.02-2.el8

Details about builds:



 NetworkManager-l2tp-1.8.6-5.el8 (FEDORA-EPEL-2021-f8c96d653c)
 NetworkManager VPN plugin for L2TP and L2TP/IPsec

Update Information:

Update to 1.8.6 release

ChangeLog:

* Sun Feb  7 2021 Douglas Kosovic  - 1.8.6-5
- Correct EPEL8 conditional
* Sun Feb  7 2021 Douglas Kosovic  - 1.8.6-4
- Sync with EPEL8
* Mon Jan 25 2021 Fedora Release Engineering  - 
1.8.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
* Fri Jan  8 2021 Tomas Hrcka  - 1.8.6-2
- rebuilt for new version of ppp
* Tue Nov  3 2020 Douglas Kosovic  - 1.8.6-1
- Updated to 1.8.6 release
- Remove redundant libnm_glib conditionals
- explictly recommend libreswan >= 4.0 because of change in NSS DB location.
- AppData file now in %{_datadir}/metainfo/
- D-Bus policy file now in %{_datadir}/dbus-1/system.d/
* Mon Jul 27 2020 Fedora Release Engineering  - 
1.8.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 darktable-3.4.1-1.el8 (FEDORA-EPEL-2021-627a19325d)
 Utility to organize and develop raw images

Update Information:

3.4.1 release

ChangeLog:

* Sat Feb  6 2021 Germano Massullo  - 3.4.1-1
- 3.4.1 release
- removed 7428.patch and 7569.patch
* Tue Jan 26 2021 Fedora Release Engineering  - 
3.4.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild




 openelp-0.9.2-1.el8 (FEDORA-EPEL-2021-371f06fb25)
 Open Source EchoLink Proxy

Update Information:

Update to OpenELP 0.9.2

ChangeLog:

* Sun Feb  7 2021 Scott K Logan  - 0.9.2-1
- Update to 0.9.2 (rhbz#1925917)

References:

  [ 1 ] Bug #1925917 - openelp-0.9.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1925917




 stress-ng-0.12.02-2.el8 (FEDORA-EPEL-2021-4860897f3e)
 Stress test a computer system in various ways

Update Information:

Bump to 0.12.02

ChangeLog:

* Sun Feb  7 2021 Chris Brown  - 0.12.02-1
- Bump to 0.12.02
* Wed Jan 27 2021 Fedora Release Engineering  - 
0.12.01-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

References:

  [ 1 ] Bug #1919034 - stress-ng-0.12.02 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1919034


___
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


[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-07 Thread Kevin Fenzi
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. 

> - We plan on creating normal EPEL9 after the RHEL 9.0 GA release, just
> like normal.  No sooner.  All epel9-next packages will be rebuilt on
> EPEL9.  They will not be "tagged over".  This rebuild should be by whoever
> built it in epel9-next.

This I am also not a fan of. What if you make a epel9-next branch for
something, but you don't (for whatever reason) want to put it in epel9?
I think we should just open new epel9 branches at epel9 time and
maintaienrs can branch and build them (again, if people don't care the
epel packagers sig can do all the ones they manage right up front).
> 
> Approximate Timelines:
> - All of these timelines depend on (A) CentOS 9 Stream / RHEL9 actual dates
> and (B) availability of EPEL volunteers.  Please note, EPEL is
> completely volunteers, and sometimes "day jobs" make EPEL timelines slip.
> - epel9-next - July 2021
> -- CentOS 9 Stream should have a public repository in April 2021
> -- Should take about 3 months to setup
> - epel9 - October 2022
> -- RHEL 9.0 should be released around May 2022
> -- Should take about 5 months to setup
> -- Note: It takes longer because it has to deal with getting packages
> from an internal RHEL repo and all the complications of doing that.
> 
> EPEL Packaging SIG
> - We hope to utilize the EPEL Packaging SIG as much as possible.
> - This might be as simple as having them rebuild a epel9-next package
> on epel9, or possibly maintaining a package when the Fedora packager
> does not want to do EPEL.

I think simple is better here. 

> - More details will be coming, but we hope the SIG will help get alot
> of the most used EPEL packages into EPEL9 as soon as possible.

Thanks for writing all this up!

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


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

2021-02-07 Thread Chris Murphy
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?

- As far as I'm aware, enabling CSM requires disabling UEFI Secure Boot.

* Any UEFI memory tester needs to be signed with Fedora's signing key,
same as grubx64.efi so that it works with UEFI Secure boot enabled.


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


Re: fedpkg import weirdness

2021-02-07 Thread Ville-Pekka Vainio
I read a bit of code and thus replying to my own message.

It seems rpkg decides whether to upload a file to the lookaside cache
or not based on running "file -b --mime-encoding" on it. For a keyring
file that returns "binary".
See https://pagure.io/rpkg/blob/master/f/pyrpkg/utils.py#_280

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


fedpkg import weirdness

2021-02-07 Thread Ville-Pekka Vainio
Hi,

I imported a new package called voikko-fi yesterday. I think I hit a
bug in fedpkg, but I'm not sure. The packaging guidelines say "Any
detached signature file (e.g. foo.tar.gz.asc or foo.tar.gz.sig) must
be uploaded to the package lookaside cache alongside the source code,
while the keyring must be committed directly to the package SCM."

I think fedpkg import did this the other way around. The keyring
(called gpgkey-AC5D65F10C8596D7E2DAE2633D309B604AE3942E.gpg) was
uploaded to the lookaside cache. The signature file (called
voikko-fi-2.4.tar.gz.asc) was about to be committed to git. I fixed
things manually as much as I could.

I don't have the shell history available anymore and I may have made
an error somewhere myself. I have not looked at the fedpkg source code
yet, it'd be interesting to know how to test the import again without
breaking anything.

-Ville-Pekka
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-07 Thread Dan Čermák
Hi Alex,

I agree that in these cases an immediate orphaning of the packages is 
justified, as the packager in question is clearly no longer active.

You might want to ask a provenpackager to push your fix directly to dist got 
though, to get the changes in place in time.


Cheers,

Dan

On February 7, 2021 6:28:13 PM UTC, Alex Perez  wrote:
>Hi folks,
> 
>I've opened https://pagure.io/fesco/issue/2574 
>[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 [mailto:si...@laptop.org] and 
>si...@sugarlabs.org [mailto: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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

2021-02-07 Thread Pavel Valena


- Original Message -
> From: "Todd Zullinger" 
> To: devel@lists.fedoraproject.org
> Sent: Saturday, February 6, 2021 5:40:06 PM
> Subject: Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow
> 
> Pierre-Yves Chibon wrote:
> > On Fri, Feb 05, 2021 at 12:11:45PM +0100, Florian Weimer wrote:
> >> Would it be possible to add the sequence of commands to the proposal to
> >> convert an existing clone with unpushed changes?
> >> 
> >> I think it is something along the lines of (for src.fedoraproject.org):
> >> 
> >> git checkout master
> >> git branch --move rawhide
> >> git branch --set-upstream-to=origin/rawhide
> >> 
> >> I'm not entire sure if “rawhide“ is the correct branch to use, and if
> >> the sequence of commands is the right one.
> > 
> > All of the above is correct.
> > 
> > I'll add it to the wiki page, thanks for the suggestion!
> 
> The `git checkout master` (or `git switch master`) can be
> omitted (at the slight cost of being more verbose with the
> `git branch` commands).
> 
> git fetch # optionally with -p / --prune
> git branch -m master rawhide
> git branch -u origin/rawhide rawhide
> 
> For folks that might have a different branch checked out
> with changes on it, the attempt to switch branches will just
> get in the way.
> 
> I had some clones which were on branches other than master
> and which contained changes.  I ran this in my Fedora git
> tree:
> 
> for i in /path/to/dist/fedora/*/; do
> (
> pushd $i && git fetch -p &&
> git branch -m master rawhide &&
> git branch -u origin/rawhide rawhide
> )
> done |& tee /path/to/output
> 
> Anyone who has used a remote name other than 'origin' will
> have to adjust that part of the command, of course.

An alternative one-liner, if you like :)

ls -d */.git/ | cut -d'/' -f1 | xargs -ri bash -c "echo; set -xe; cd '{}'; git 
fetch origin; git branch -m master rawhide; git branch -u origin/rawhide 
rawhide"

Pavel

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


Request for exception to non-responsive maintainer policy for Sugar packages

2021-02-07 Thread Alex Perez
Hi folks,
 
I've opened https://pagure.io/fesco/issue/2574 
[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 [mailto:si...@laptop.org] and si...@sugarlabs.org 
[mailto: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___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Review swap: voikko-fi (for Finnish spell-checking)

2021-02-07 Thread Ville-Pekka Vainio
Hi all,

This work is finally done and the packages are in Rawhide, in good
time before the beta. Thank you Miro and Zbyszek!
I think I found a fedpkg import bug while importing voikko-fi from
SRPM, I'll make a new thread about that.

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


[Test-Announce] Proposal to CANCEL: 2021-02-08 Fedora QA Meeting

2021-02-07 Thread Adam Williamson
Hi folks! I'm proposing we cancel the QA meeting tomorrow. I don't have
anything urgent this week.

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

Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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


Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

2021-02-07 Thread Antonio T. sagitter

These errors are solved in IceCat with following patch:

https://src.fedoraproject.org/rpms/icecat/blob/902a94597e0d48bbe3e1ebc3184787f7b6fe9242/f/icecat-78.7.1-fix_error_template_with_C_linkage.patch

On 2/6/21 11:04 PM, Germano Massullo wrote:

Also this build seems to be related to this problem
https://koji.fedoraproject.org/koji/taskinfo?taskID=61482059
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


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: Xen support dead?

2021-02-07 Thread W. Michael Petullo
Another Xen-related bug that has continued through a number of releases
has to do with the interaction between Xen and SELinux. The SELinux
policy prevents xenstored from functioning.

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

I am glad to see movement on BZ #1858364, and I am happy to provide any
information necessary to fix this SELinux issue too.

-- 
Mike

:wq
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-07 Thread Zbigniew Jędrzejewski-Szmek
On Sun, Feb 07, 2021 at 11:03:38AM -0500, Stephen John Smoogen wrote:
> On Sun, 7 Feb 2021 at 09:41, Roberto Ragusa  wrote:
> 
> > On 2/7/21 12:16 PM, drago01 wrote:
> > > It can only be an alternative, not a replacement, since it is
> > dropping features:
> > >
> > > «In particular, no attempt is made to measure the cache and main
> > memory speed,
> > > or to identify and report the DRAM type.»
> > >
> > >
> > >   Which is nice to have but not really the point of a memory tester ...
> >
> > I'm pointing out that memtest86+ is not just a memory tester.
> > Is there any other tool covering that functionality?

Memory type and speed information is available through dmi. In systemd we
recently merged a patch [1] to make this information available to unprivileged
users, so that gnome can display it in a pretty way:

$ udevadm info /sys/class/dmi/id/
P: /devices/virtual/dmi/id
...
E: MODALIAS=dmi:bvnLENOVO:bvrN1FET68W(1.42):bd03/13/2019...
...
E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
E: MEMORY_ARRAY_NUM_DEVICES=2
...
E: MEMORY_DEVICE_0_SIZE=4294967296
E: MEMORY_DEVICE_0_FORM_FACTOR=Chip
E: MEMORY_DEVICE_0_TYPE=LPDDR3
E: MEMORY_DEVICE_0_SPEED_MTS=1867
E: MEMORY_DEVICE_0_MANUFACTURER=Samsung
E: MEMORY_DEVICE_0_PART_NUMBER=K4E6E304EE-EGCF
...
E: MEMORY_DEVICE_1_SIZE=4294967296
E: MEMORY_DEVICE_1_FORM_FACTOR=SODIMM
E: MEMORY_DEVICE_1_LOCATOR=ChannelB
E: MEMORY_DEVICE_1_BANK_LOCATOR=BANK 2
E: MEMORY_DEVICE_1_TYPE=LPDDR3
...

[1] https://github.com/systemd/systemd/pull/17837

This is just repeated from what the firmware gives us, not measured,
but might be good enough.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-07 Thread John Reiser

«In particular, no attempt is made to measure the cache and main memory 
speed,
or to identify and report the DRAM type.»


  Which is nice to have but not really the point of a memory tester ...


When the tester reports errors then it is handy to know as much as possible
about where the errors lie, including the manufacturer and part number
if an error can be isolated to an address range.  For a system which
added memory in mid-life using a different brand of RAM, it is helpful
to confirm the brand which is failing.  /usr/sbin/dmidecode reports
what it knows, but that requires cross-referencing etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-07 Thread Stephen John Smoogen
On Sun, 7 Feb 2021 at 09:41, Roberto Ragusa  wrote:

> On 2/7/21 12:16 PM, drago01 wrote:
> >
> > On Sunday, February 7, 2021, Roberto Ragusa  > wrote:
> >
> > It can only be an alternative, not a replacement, since it is
> dropping features:
> >
> > «In particular, no attempt is made to measure the cache and main
> memory speed,
> > or to identify and report the DRAM type.»
> >
> >
> >   Which is nice to have but not really the point of a memory tester ...
>
> I'm pointing out that memtest86+ is not just a memory tester.
> Is there any other tool covering that functionality?
>
>
Probably not because for more and more modern hardware it gets harder and
harder to get that information. Heck even 'testing' memory is hard enough
these days because a lot of hardware is built around covering up any
problem with the hardware because it is expected to fail and the hardware
itself will see that, mark it bad and set something else up as good.

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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] Xfce 4.16 on EPEL-8

2021-02-07 Thread Mukundan Ragavan


Hi all,

I have a COPR containing xfce 4.16 packages for EPEL-8 packages [0]. I 
would like to get some testing done using this COPR before getting into 
EPEL-8.


Please email if and when you notice problems and I will try to fix it as 
soon as possible.


As a reminder - xfce 4.16 will be available in F34.

Thanks,
Mukundan.


[0] https://copr.fedorainfracloud.org/coprs/nonamedotc/xfce416-epel8/
--
GPG Key: E5C8BC67


OpenPGP_signature
Description: OpenPGP digital 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


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

2021-02-07 Thread Roberto Ragusa

On 2/7/21 12:16 PM, drago01 wrote:


On Sunday, February 7, 2021, Roberto Ragusa mailto:m...@robertoragusa.it>> wrote:

It can only be an alternative, not a replacement, since it is dropping 
features:

«In particular, no attempt is made to measure the cache and main memory 
speed,
or to identify and report the DRAM type.»


  Which is nice to have but not really the point of a memory tester ...


I'm pointing out that memtest86+ is not just a memory tester.
Is there any other tool covering that functionality?

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


[Bug 1925872] perl-Business-ISBN-Data-20210112.002 is available

2021-02-07 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1925872

Paul Howarth  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Business-ISBN-Data-202
   ||10112.002-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2021-02-07 13:24:25



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=61524168


-- 
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 1925872] perl-Business-ISBN-Data-20210112.002 is available

2021-02-07 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1925872

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |p...@city-fan.org
   Doc Type|--- |If docs needed, set a value




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


Re: Fedora CoreOS Virtual Meetup this week

2021-02-07 Thread Zbigniew Jędrzejewski-Szmek
On Sat, Feb 06, 2021 at 10:41:16AM +0100, Clement Verna wrote:
> Recordings are available on Fedora's youtube channel
> 
> Growing Fedora CoreOS Community :
> https://www.youtube.com/watch?v=HSuBWeosAvQ
> Fedora CoreOS as an Official Edition :
> https://www.youtube.com/watch?v=t5VAw8NRXNc
> 
> You can also find the discussions notes here :
> https://github.com/coreos/fedora-coreos-tracker/pull/732/files -
> Pull-request but that should be merged soon :)

Hi Clement,

thanks for making those available.

I listened avidly to the discussion, and here's my take on the subject
of "FCOS as Edition":

in the discussion, you asked whether there should be "FCOS 33", "FCOS
34", etc, and the answer was an emphatic "no". My answer is "yes".
What do I mean by that?  I think it's fine to have a *goal* of just a
smooth FCOS stream, i.e. to make the underlying Fedora version
unimportant to users. But as a practical matter, it'll not be
achievable and FCOS should instead accept that as long as FCOS is
based on Fedora, the choices that Fedora "proper" makes and the
cadence of releases will be visible in FCOS. As mentioned in the
discussion "the package set is fairly vanilla bodhi stable with a bit
of delay for the two week promotion timing". Even if FCOS is just a
subset of those packages, the semiannual jump in package versions and
configuration choices must be visible to some extent.

There seems to be a broad consensus that FCOS should participate more in
the Fedora Change process: both to monitor announced Changes and to
announce changes in FCOS using a similar process.

But I think FCOS should go a step further, and also *declare* that it
follows the Fedora schedule. I do *not* mean by that FCOS stable
stream should by switched on the same day that other Fedora editions
make a release. The two week delay is quite reasonable. (In fact,
seasoned users of Fedora "proper" know not to update immediately on
the release day, and instead wait two or three weeks for wrinkles to
be ironed out. Since FCOS does updates automatically, I think it's
totally reasonable to bake such a delay into the plan.) But we should
be able to say, in the release announcements, that "Workstation,
Server, etc. release today, and FCOS switch of stable stream will
follow in two weeks, if no last minute bugs are discovered. Users who
want to preview the next version, should use the devel stream."

Matthew said that users should be able to see all editions on
getfedora.org, and it would be great to also have FCOS there, but it
means that FCOS stable must be available on a predictable schedule.

I think that tying FCOS to the the release schedule of other editions
will actually be more of a change in perception than any reality,
since FCOS already is following the bodhi update stream. FCOS has the
ability to delay some changes and to apply local overrides. But doing
that burns FCOS maintainer time, and ideally, should not be
necessary. But changes that are bad for FCOS are probably bad for at
least some users of other editions. *If* FCOS embraces the Change
process and the effect of any and all changes on FCOS is evaluated
early enough, those "downstream" overrides in FCOS should be replaced
by fixes in the packages themselves, with a benefit to non-FCOS users
too.

In summary, becoming an Edition goes both ways: it constrains what
FCOS can do, but it also allows FCOS to influence what happens in
Fedora "proper". Marketing FCOS and other editions together will offer
our users a more complete choice and strengthen the Fedora brand.
It'll also make FCOS more visible and more trusted.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20210207.n.0 compose check report

2021-02-07 Thread Fedora compose checker
Missing expected images:

Xfce raw-xz armhfp
Minimal raw-xz armhfp

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

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

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

ID: 771236  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/771236
ID: 771280  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/771280
ID: 771322  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/771322
ID: 771467  Test: aarch64 universal install_kickstart_firewall_disabled@uefi
URL: https://openqa.fedoraproject.org/tests/771467

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

ID: 771213  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/771213
ID: 771245  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/771245
ID: 771249  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/771249
ID: 771250  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/771250
ID: 771287  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/771287
ID: 771300  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/771300
ID: 771305  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/771305
ID: 771310  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/771310
ID: 771352  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/771352
ID: 771358  Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/771358
ID: 771365  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/771365
ID: 771427  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/771427
ID: 771436  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/771436
ID: 771445  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/771445
ID: 771458  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/771458
ID: 771479  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/771479
ID: 771482  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/771482
ID: 771489  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/771489
ID: 771490  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/771490
ID: 771491  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/771491

Soft failed openQA tests: 58/183 (x86_64), 35/124 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 771182  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/771182
ID: 771183  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/771183
ID: 771190  Test: x86_64 Server-dvd-iso install_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/771190
ID: 771192  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/771192
ID: 771193  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/771193
ID: 771195  Test: x86_64 Server-dvd-iso install_resize_lvm
URL: https://openqa.fedoraproject.org/tests/771195
ID: 771196  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/771196
ID: 771232  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/771232
ID: 771240  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/771240
ID: 771296  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/771296
ID: 771366  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/771366
ID: 771370  Test: x86_64 universal install_blivet_btrfs
URL: 

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

2021-02-07 Thread drago01
On Sunday, February 7, 2021, Roberto Ragusa  wrote:

> On 2/7/21 10:07 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].
>>
>
> It can only be an alternative, not a replacement, since it is dropping
> features:
>
> «In particular, no attempt is made to measure the cache and main memory
> speed,
> or to identify and report the DRAM type.»


 Which is nice to have but not really the point of a memory tester ...


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


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

2021-02-07 Thread Roberto Ragusa

On 2/7/21 10:07 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].


It can only be an alternative, not a replacement, since it is dropping features:

«In particular, no attempt is made to measure the cache and main memory speed,
or to identify and report the DRAM type.»

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


Fedora rawhide compose report: 20210207.n.0 changes

2021-02-07 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20210206.n.0
NEW: Fedora-Rawhide-20210207.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  3
Dropped packages:0
Upgraded packages:   130
Downgraded packages: 0

Size of added packages:  1.86 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.42 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20210207.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: ghc-http-query-0.1.0-1.fc34
Summary: Simple http queries
RPMs:ghc-http-query ghc-http-query-devel ghc-http-query-doc 
ghc-http-query-prof
Size:375.42 KiB

Package: perl-Test-DiagINC-0.008-2.fc34
Summary: List modules and versions loaded if tests fail
RPMs:perl-Test-DiagINC
Size:22.87 KiB

Package: voikko-fi-2.4-3.fc34
Summary: A description of Finnish morphology written for libvoikko
RPMs:voikko-fi
Size:1.47 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ClanLib06-0.6.5-53.fc34
Old package:  ClanLib06-0.6.5-50.fc33
Summary:  Version 0.6 of this Cross platform C++ game library
RPMs: ClanLib06 ClanLib06-devel
Size: 6.11 MiB
Size change:  -20.06 KiB
Changelog:
  * Mon Sep 14 2020 Jeff Law  - 0.6.5-51
  - Explicitly include  for NULL as its not implicitly included
by gcc-11's header files

  * Mon Jan 25 2021 Fedora Release Engineering  - 
0.6.5-52
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sat Feb 06 2021 Hans de Goede  - 0.6.5-53
  - Fix joystick-support (rhbz#1860696)


Package:  Hermes-1.3.3-37.fc34
Old package:  Hermes-1.3.3-36.fc34
Summary:  Pixel format conversion library
RPMs: Hermes Hermes-devel
Size: 753.10 KiB
Size change:  10.67 KiB
Changelog:
  * Sat Feb 06 2021 Hans de Goede  1.3.3-37
  - Regenerate the autofoo files, esp. libtool, to fix missing symbols on i686
  - Modernize the spec file a bit


Package:  auriferous-1.0.1-34.fc34
Old package:  auriferous-1.0.1-33.fc33
Summary:  Game inspired by the classic Loderunner
RPMs: auriferous
Size: 77.99 MiB
Size change:  -2.69 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
1.0.1-34
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


Package:  bout++-4.3.2-6.fc34
Old package:  bout++-4.3.2-3.fc34
Summary:  Library for the BOUndary Turbulence simulation framework
RPMs: bout++-common bout++-doc bout++-mpich bout++-mpich-devel 
bout++-openmpi bout++-openmpi-devel python3-bout++ python3-bout++-mpich 
python3-bout++-openmpi
Size: 28.54 MiB
Size change:  -225.89 KiB
Changelog:
  * Sun Jan 17 2021 David Schw??rer  4.3.2-4
  - Increase timeout for tests RHBZ#1914777

  * Tue Jan 26 2021 Fedora Release Engineering  - 
4.3.2-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sat Feb 06 2021 David Schw??rer  4.3.2-6
  - Increase timeout for test coordinates-initialization


Package:  breeze-icon-theme-5.79.0-2.fc34
Old package:  breeze-icon-theme-5.78.0-2.fc34
Summary:  Breeze icon theme
RPMs: breeze-icon-theme breeze-icon-theme-rcc
Size: 8.63 MiB
Size change:  111.06 KiB
Changelog:
  * Sat Feb 06 2021 Rex Dieter  - 5.79.0-1
  - 5.79.0

  * Sat Feb 06 2021 Rex Dieter  - 5.79.0-2
  - respin


Package:  chromium-88.0.4324.150-1.fc34
Old package:  chromium-88.0.4324.96-4.fc34
Summary:  A WebKit (Blink) powered web browser
RPMs: chrome-remote-desktop chromedriver chromium chromium-common 
chromium-headless
Size: 424.61 MiB
Size change:  92.78 KiB
Changelog:
  * Tue Feb 02 2021 Tom Callaway  - 88.0.4234.146-1
  - update to 88.0.4234.146

  * Fri Feb 05 2021 Tom Callaway  - 88.0.4234.150-1
  - update to 88.0.4234.150


Package:  clanbomber-1.05-39.fc34
Old package:  clanbomber-1.05-37.fc33
Summary:  Lay bombs and Blast the other players of the field game using 
ClanLib
RPMs: clanbomber
Size: 9.63 MiB
Size change:  -10.08 KiB
Changelog:
  * Wed Nov 04 2020 Jeff Law  - 1.05-38
  - Fix missing #include for gcc-11

  * Tue Jan 26 2021 Fedora Release Engineering  - 
1.05-39
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


Package:  cqrlog-2.5.1-1.fc34
Old package:  cqrlog-2.5.0-2.fc34
Summary:  An amateur radio contact logging program
RPMs: cqrlog
Size: 61.81 MiB
Size change:  34.49 KiB
Changelog:
  * Tue Feb 02 2021 Richard Shaw  - 2.5.0-3
  - Rebuild for hamlib 4.1.

  * Fri Feb 05 2021 Richard Shaw  - 2.5.1-1
  - Update to 2.5.1.


Package:  dfu-util-0.10-1.fc34
Old package:  dfu-util-0.9-11.fc34
Summary:  USB Device Firmware Upgrade tool
RPMs: dfu-util
Size: 284.38 KiB
Size change:  28.86 KiB
Changelog:
  * Sat Feb 06 2021 Peter

Fedora-Cloud-32-20210207.0 compose check report

2021-02-07 Thread Fedora compose checker
No missing expected images.

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

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

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

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

2021-02-07 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1925899

Bug ID: 1925899
   Summary: perl-JavaScript-Minifier-XS-0.14 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-JavaScript-Minifier-XS
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.14
Current version/release in rawhide: 0.13-2.fc34
URL: http://search.cpan.org/dist/JavaScript-Minifier-XS/

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


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


New memory tester application potentially to replace memtest86+: PCMemTest

2021-02-07 Thread Neal Gompa
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