Removing packages from module

[Aleksei Bavshin]

Hi,

I'm considering dropping some packages from sway:rolling modulemd
definition, however I don't clearly understand what would be the
resulting upgrade behavior.

Let's assume that the module is already enabled and all the packages are
installed in the user's system. Also, the module was containing the same
set of packages during f32 release (i.e. in fedora-modular).

In an optimistic case I'd like to believe that once the package is
removed from the modulemd file and a new module update is published, the
override magic hacked into dnf would stop masking package from
non-modular repository. NEVRA would be the only factor deciding the
update priority and when we push new build of the package into
f32-updates it would update the remaining modular build of the package
with lower EVR.

In a pessimistic case I expect that the package removed from the module
will never be updated by dnf in the same release cycle since the already
installed version originates from the modular repository. Upgrade to f33
would require module reset.

I have zero knowledge on the modularity implementation so I would
appreciate if anyone could clarify which behavior is more likely to
happen before we start experimenting on real users :)

-- 
With best regards,
Aleksei Bavshin



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

[389-devel] 389 DS nightly 2020-07-17 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/17/report-389-ds-base-1.4.4.4-20200716gitc0688a0.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

wlroots soname bump

[Aleksei Bavshin]

Hi list,

wlroots will be updated to 0.11.0 in rawhide next week.
The update breaks API/ABI and will change soversion from 5 to 6.

Dependent packages:
 - phoc
 - sway
 - wayfire

For all affected packages I identified either upstream release or
interim patches restoring their functionality. I already sent details to
a narrower list of recipients and I'll contact maintainers of the
affected packages once more when we publish the wlroots build.

--
With best regards,
Aleksei Bavshin



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: Ditch RPM in favor of DPKG

[Ian Kent]

On Thu, 2020-07-16 at 10:11 +, Dridi Boukelmoune wrote:
> > Simply put, "no". Debian and Ubuntu ".deb" packages too often don't
> > follow the File System Hierarchy, they may have different layouts
> > and
> > package naming capitalization schemes for matching Fedora packagers
> > like "PyYAML", they may have overlapping pre-set uids and
> > mismatched
> > group name conventions, etc., etc, and the grub intigration for new
> > kernels is likely to be a nightmare. It would be a full-time job
> > for
> > several competent engineers to do that kind of package impedance
> > matching.
> 
> I'm not interested in debating Debian and derivatives packaging
> guidelines, but I generally prefer how Fedora does things (except
> notably, modularity).

I have to say that, from my perspective due to past experience, having
to use the Debian/Ubuntu packaging for development in Fedora would
have me scrambling to find another distribution for my desktop.

While dpkg is just a learning curve thing, rpm is much simpler when
doing development/bug fixing for me. Indeed the fact that Fedora used
rpm is one of reasons I have continued to use Fedora for my desktop
for so many years.

Oddly, the subject of the original post infers getting rid of rpm but
the post itself sounds like it's proposing something different and
that's why I decided to speak up.

Ian
___
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 1149524] Review Request: perl-Digest-Whirlpool - Interface to Whirlpool hash algorithm

[bugzilla]

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

David Dick  changed:

   What|Removed |Added

  Flags|fedora-review?  |fedora-review- needinfo-
   |needinfo?(dd...@cpan.org)   |



--- Comment #5 from David Dick  ---
Hi Denis, can you get someone else to look at this.  I'm just flat out atm.


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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 702  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 441  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
 151  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6   
python-waitress-1.4.3-1.el7
  91  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465   
python34-3.4.10-5.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0f25da8099   
python-rsa-3.4.2-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-28cc1451e0   
python-gnupg-0.4.6-2.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8dd45257ad   
seamonkey-2.53.3-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2f9c63b80c   
php-horde-kronolith-4.2.29-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dab5d98f39   
cacti-1.2.13-1.el7 cacti-spine-1.2.13-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-07adc005e6   
mbedtls-2.7.16-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-30513f3084   
singularity-3.6.0-1.el7


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

HepMC3-3.2.2-2.el7
composer-1.10.9-1.el7
flatpak-module-tools-0.12-1.el7
php-composer-spdx-licenses-1.5.4-1.el7
python-rosinstall_generator-0.1.22-1.el7
root-6.22.00-2.el7
xrootd-4.12.3-2.el7

Details about builds:



 HepMC3-3.2.2-2.el7 (FEDORA-EPEL-2020-4fb6379dce)
 C++ Event Record for Monte Carlo Generators

Update Information:

Update to root vesrion 6.22.00  - New and improved Python bindings - Dropped the
python3-other packages (EPEL 7) - The new Python bindings has split the TPython
interface to a separate library. Now in a separate root-tpython package - root-
tpython and root-tmva-python are now using Python 3 on EPEL 7

ChangeLog:

* Tue Jul 14 2020 Mattias Ellert  - 3.2.2-2
- Rebuild for root 6.22.00

References:

  [ 1 ] Bug #1849668 - root-tmva-r missing dependencies
https://bugzilla.redhat.com/show_bug.cgi?id=1849668




 composer-1.10.9-1.el7 (FEDORA-EPEL-2020-9f62416fac)
 Dependency Manager for PHP

Update Information:

**Version 1.10.9**  *Fixed Bitbucket redirect loop when credentials are
outdated *Fixed GitLab auth prompt wording *Fixed self-update handling
of files requiring admin permissions to write to on Windows (it now does a UAC
prompt) *Fixed parsing issues in funding.yml files

ChangeLog:

* Thu Jul 16 2020 Remi Collet  - 1.10.9-1
- update to 1.10.9




 flatpak-module-tools-0.12-1.el7 (FEDORA-EPEL-2020-80b4de8c34)
 Tools for maintaining Flatpak applications and runtimes as Fedora modules

Update Information:

Version 0.12 changes the default for locally built containers to have Flatpak
metadata in both labels and annotations by default, and fixes a problem
installing Flatpaks container images created by recent versions of Flatpak.
  This update adds some fixes to make local builds work correctly with
recent versions of dnf and mock.

ChangeLog:

* Thu Jul 16 2020 Fedora  - 0.12-1
- Version 0.12 - fix installing Flatpaks created by flatpak-1.6
* Tue Jul 14 2020 Owen Taylor  - 0.11.5-2
- Bump and rebuild (built twice and got Koji confusd)
* Tue Jul 14 2020 Owen Taylor  - 0.11.5-1
- Version 0.11.5 - compatibility fixes for recent dnf and mock




 php-composer-spdx-licenses-1.5.4-1.el7 (FEDORA-EPEL-2020-9b41fff77d)
 SPDX licenses list and validation library

Update Information:

**Version 1.5.4** - 2020-07-15  * Changed: updated licenses list to SPDX 3.9

ChangeLog:

* Thu Jul 16 2020 Remi Collet  - 1.5.4-1
- update to 

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8c3e76982e   
python-rsa-3.4.2-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7b550f6ce5   
python-gnupg-0.4.6-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e44380bc7a   
php-horde-kronolith-4.2.29-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e54cfb4880   
singularity-3.6.0-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f275c3fe6a   
mbedtls-2.7.16-1.el6


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

xrootd-4.12.3-2.el6

Details about builds:



 xrootd-4.12.3-2.el6 (FEDORA-EPEL-2020-da1e76a67d)
 Extended ROOT file server

Update Information:

Backport fixes for the XrdVoms plugin from git.

ChangeLog:

* Thu Jul 16 2020 Mattias Ellert  - 1:4.12.3-2
- Fix a typo in the rpm scriptlets (missing underscore)
* Mon Jul 13 2020 Mattias Ellert  - 1:4.12.3-1
- Update to version 4.12.3 (no code changes w.r.t. 4.12.2)
- Backport XrdVoms fixes from upstream git


___
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

[Bug 1852856] perl-Template-Toolkit depends on mod_perl, which eventually installs httpd

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Template-Toolkit-2.29-
   ||4.el8
 Resolution|--- |ERRATA
Last Closed||2020-07-17 01:17:20



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-b01f134c3e has been pushed to the Fedora EPEL 8 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 1691325] Upgrade perl-Net-DNS-SEC to 1.12

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-93ae48c574 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-93ae48c574`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-93ae48c574

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


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

[Bug 1708214] Upgrade perl-Net-DNS-SEC to 1.17

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-93ae48c574 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-93ae48c574`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-93ae48c574

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


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

[EPEL-devel] Re: Problems with yum update

[warron.french]

Hello Kevin, I did as you suggested and a statement indicated it would be
good to reboot was displayed, so I did reboot.

After that my generic *yum update* did work.
Then I tried to install EPEL Repo again:
[root@wsf-owt-dev001:yum.repos.d]# yum install
https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
Last metadata expiration check: 4:20:17 ago on Thu 16 Jul 2020 03:35:37 PM
EDT.
[MIRROR] epel-release-latest-8.noarch.rpm: Curl error (60): Peer
certificate cannot be authenticated with given CA certificates for
https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm [SSL
certificate problem: EE certificate key too weak]
[MIRROR] epel-release-latest-8.noarch.rpm: Curl error (60): Peer
certificate cannot be authenticated with given CA certificates for
https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm [SSL
certificate problem: EE certificate key too weak]
[MIRROR] epel-release-latest-8.noarch.rpm: Curl error (60): Peer
certificate cannot be authenticated with given CA certificates for
https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm [SSL
certificate problem: EE certificate key too weak]
[MIRROR] epel-release-latest-8.noarch.rpm: Curl error (60): Peer
certificate cannot be authenticated with given CA certificates for
https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm [SSL
certificate problem: EE certificate key too weak]
[FAILED] epel-release-latest-8.noarch.rpm: Curl error (60): Peer
certificate cannot be authenticated with given CA certificates for
https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm [SSL
certificate problem: EE certificate key too weak]
Curl error (60): Peer certificate cannot be authenticated with given CA
certificates for
https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm [SSL
certificate problem: EE certificate key too weak]



--
Warron French



On Thu, Jul 16, 2020 at 5:39 PM Kevin Fenzi  wrote:

> On Thu, Jul 16, 2020 at 04:29:08PM -0400, warron.french wrote:
> > Actually the file indicates DEFAULT already.
>
> Odd. Thats the only time I have seen any errors like those.
>
> YOu might try a sudo update-crypto-policies --set DEFAULT
> and see if it helps anyhow.
>
> kevin
> --
> >
> > --
> > Warron French
> >
> >
> >
> > On Thu, Jul 16, 2020 at 4:12 PM Kevin Fenzi  wrote:
> >
> > > On Thu, Jul 16, 2020 at 03:59:23PM -0400, warron.french wrote:
> > > > I work in a lab environment that has a proxy somewhere on the
> network.
> > > >
> > > > I have my VMware VM running CentOS8 and have installed the
> > > > epel-latest-release package.
> > > snip...
> > > >
> > > > I don't know what to do to fix this.  Can someone please explain
> what the
> > > > problem is on a high level and then what to do about it so that I can
> > > learn
> > > > from this?
> > >
> > > What does:
> > >
> > > cat /etc/crypto-policies/state/current
> > >
> > > show?
> > >
> > > If it's FUTURE, thats the problem. You can do back to default with:
> > >
> > > sudo update-crypto-policies --set DEFAULT
> > >
> > > kevin
> > > ___
> > > 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 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 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 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: 

[EPEL-devel] Re: Problems with yum update

[Orion Poplawski]

On 7/16/20 1:59 PM, warron.french wrote:

I work in a lab environment that has a proxy somewhere on the network.

I have my VMware VM running CentOS8 and have installed the 
epel-latest-release package.


When I execute a generic *yum update *I run into problems.  They are here:
[root@wsf-owt-dev001:yum.repos.d]# yum update Extra Packages for 
Enterprise Linux 8 - Playground - x86_64 0.0 B/s | 0 B 00:01 Errors 
during downloading metadata for repository 'epel-playground': - Curl 
error (60): Peer certificate cannot be authenticated with given CA 
certificates for 
https://mirrors.fedoraproject.org/metalink?repo=playground-epel8=x86_64=stock=centos 
[SSL certificate problem: EE certificate key too weak] Error: Failed to 
download metadata for repo 'epel-playground': Cannot prepare internal 
mirrorlist: Curl error (60): Peer certificate cannot be authenticated 
with given CA certificates for 
https://mirrors.fedoraproject.org/metalink?repo=playground-epel8=x86_64=stock=centos 
[SSL certificate problem: EE certificate key too weak]


I see the curl error, so I try a curl command and also run into problems:
[root@wsf-owt-dev001:yum.repos.d]# curl -v 
https://mirrors.fedoraproject.org/metalink?repo=playground-epel8=x86_64=stock=centos 
[1] 683465 [2] 683466 [3] 683467 [root@wsf-owt-dev001:yum.repos.d]# * 
Uses proxy env variable https_proxy == 'http://214.3.129.49:80' * Trying 
214.3.129.49... * TCP_NODELAY set * Connected to 214.3.129.49 
(214.3.129.49) port 80 (#0) * allocate connect buffer! * Establish HTTP 
proxy tunnel to mirrors.fedoraproject.org:443 
 > CONNECT 
mirrors.fedoraproject.org:443  
HTTP/1.1 > Host: mirrors.fedoraproject.org:443 
 > User-Agent: curl/7.61.1 > 
Proxy-Connection: Keep-Alive > < HTTP/1.0 200 Connection established < * 
Proxy replied 200 to CONNECT request * CONNECT phase completed! * ALPN, 
offering h2 * ALPN, offering http/1.1 * successfully set certificate 
verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: 
none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CONNECT phase 
completed! * CONNECT phase completed! * TLSv1.3 (IN), TLS handshake, 
Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * 
TLSv1.2 (OUT), TLS alert, bad certificate (554): * SSL certificate 
problem: EE certificate key too weak * Closing connection 0 curl: (60) 
SSL certificate problem: EE certificate key too weak More details here: 
https://curl.haxx.se/docs/sslcerts.html curl failed to verify the 
legitimacy of the server and therefore could not establish a secure 
connection to it. To learn more about this situation and how to fix it, 
please visit the web page mentioned above. [1] Exit 60 curl -v 
https://mirrors.fedoraproject.org/metalink?repo=playground-epel8 [2]- 
Done arch=x86_64 [3]+ Done infra=stock


I don't know what to do to fix this.  Can someone please explain what 
the problem is on a high level and then what to do about it so that I 
can learn from this?


What's the output of:

curl --trace-ascii - 
'https://mirrors.fedoraproject.org/metalink?repo=playground-epel8=x86_64=stock=centos'



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



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Heads up: changing the subject format of change proposal announcements

[Samuel Sieb]

On 7/16/20 2:37 PM, Ben Cotton wrote:

On Thu, Jul 16, 2020 at 4:20 PM Jonathan Wakely
 wrote:


FCP33 seems a bit cryptic. F33 CHANGE is self-explanatory.


Agreed. No need to invent initialisms unnecessarily.

I could go with something like:


F$version Change proposal: $title - $type


For example:


F33 Change proposal: Replace Linux kernel with BSD kernel - System-Wide


The main thing that needs to stand out, from what I've read here, is
that it is a change proposal. The version and type are less important
from a "looking at the subject quickly" perspective.


No, the bigger thing is having the proposal title visible.  So this last 
suggestion is now a big regression nearly back to what it was originally.

___
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: Problems with yum update

[Kevin Fenzi]

On Thu, Jul 16, 2020 at 04:29:08PM -0400, warron.french wrote:
> Actually the file indicates DEFAULT already.

Odd. Thats the only time I have seen any errors like those. 

YOu might try a sudo update-crypto-policies --set DEFAULT
and see if it helps anyhow.

kevin
--
> 
> --
> Warron French
> 
> 
> 
> On Thu, Jul 16, 2020 at 4:12 PM Kevin Fenzi  wrote:
> 
> > On Thu, Jul 16, 2020 at 03:59:23PM -0400, warron.french wrote:
> > > I work in a lab environment that has a proxy somewhere on the network.
> > >
> > > I have my VMware VM running CentOS8 and have installed the
> > > epel-latest-release package.
> > snip...
> > >
> > > I don't know what to do to fix this.  Can someone please explain what the
> > > problem is on a high level and then what to do about it so that I can
> > learn
> > > from this?
> >
> > What does:
> >
> > cat /etc/crypto-policies/state/current
> >
> > show?
> >
> > If it's FUTURE, thats the problem. You can do back to default with:
> >
> > sudo update-crypto-policies --set DEFAULT
> >
> > kevin
> > ___
> > 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 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



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: Heads up: changing the subject format of change proposal announcements

[Ben Cotton]

On Thu, Jul 16, 2020 at 4:20 PM Jonathan Wakely
 wrote:
>
> FCP33 seems a bit cryptic. F33 CHANGE is self-explanatory.
>
Agreed. No need to invent initialisms unnecessarily.

I could go with something like:

> F$version Change proposal: $title - $type

For example:

> F33 Change proposal: Replace Linux kernel with BSD kernel - System-Wide

The main thing that needs to stand out, from what I've read here, is
that it is a change proposal. The version and type are less important
from a "looking at the subject quickly" perspective.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

.NET Core on Aarch64 - Fedora 33 Self-Contained Change proposal

[Ben Cotton]

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

== Summary ==

.NET Core will now be available on Fedora on aarch64, in addition to x86_64.

== Owner ==
* Name: [[User:omajid| Omair Majid]], [[SIGs/DotNet|DotNet SIG]]
* Email: oma...@redhat.com, dotnet-...@lists.fedoraproject.org

== Detailed Description ==
Fedora currently includes .NET Core only on x86_64. We want to make
.NET Core available on Aarch64 as well for our users.

.NET Core documentation calls the Linux/aarch64 platform "linux-arm64".

This platform has been supported by upstream .NET Core for a little
while now (2 years or so). But upstream cross-compile it on x86_64.
With recent upstream improvements, we can now build .NET Core for
aarch64 on aarch64.

In the spirit of being First on Fedora, we want to make .NET Core
available for aarch64 on Fedora.

== Feedback ==
We don't have any feedback at this time from the community.

Upstream is enthusiastic and supportive of us enabling this in Fedora.

== Benefit to Fedora ==

This change improves the coverage of Fedora packages on aarch64. .NET
Core was previously only available on x86_64; it's now available on
aarch64 as well. Users who are using Fedora on aarch64 can now use the
normal distribution packages for .NET Core, instead of having to find,
download an installing .NET Core some other way. As a result of this,
Fedora becomes a more attractive target for developing and deploying
applications on aarch64.

== Scope ==
* Proposal owners:

# Will update .NET Core to bootstrap and build on aarch64 (along with
x86_64). This shouldn't affect any other packages.
# Will work with package owners of packages that .NET Core depends on
if those specific dependencies of .NET Core are broken, buggy or
un-available on aarch64

* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (checked with #fedora-releng)
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
There is no known impact on upgrades.

.NET Core was just not available Fedora for aarch64 in previous
releases of Fedora. It will be available in Fedora starting Fedora 33.

.NET Core is not a dependency of any other package, so users running
Fedora on aarch64 and then upgrading from Fedora 32 to 33 will not
automatically pull it in. They will have to install it manually.

== How To Test ==

# Install Fedora 33 on aarch64
# Install .NET Core: sudo dnf install dotnet-sdk-3.1
# Run .NET Core: dotnet --info

The above steps should install .NET Core and show the .NET Core SDK
and Runtime version numbers. There should be no error messages or any
other failures.

== User Experience ==

- Users using Fedora on aarch64 as a platform for .NET Core
development will be able to use the Fedora-provided packages for .NET
Core

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: Proposal owner will revert packaging changes
and switch back to how .NET Core was built in Fedora 32.
* Blocks release? No
* Blocks product? No

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
.NET Core is now available on aarch64! You can install .NET Core on
Fedora on aarch64 using the normal packaging tools: sudo dnf
install dotnet-sdk-3.1


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

.NET Core on Aarch64 - Fedora 33 Self-Contained Change proposal

[Ben Cotton]

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

== Summary ==

.NET Core will now be available on Fedora on aarch64, in addition to x86_64.

== Owner ==
* Name: [[User:omajid| Omair Majid]], [[SIGs/DotNet|DotNet SIG]]
* Email: oma...@redhat.com, dotnet-...@lists.fedoraproject.org

== Detailed Description ==
Fedora currently includes .NET Core only on x86_64. We want to make
.NET Core available on Aarch64 as well for our users.

.NET Core documentation calls the Linux/aarch64 platform "linux-arm64".

This platform has been supported by upstream .NET Core for a little
while now (2 years or so). But upstream cross-compile it on x86_64.
With recent upstream improvements, we can now build .NET Core for
aarch64 on aarch64.

In the spirit of being First on Fedora, we want to make .NET Core
available for aarch64 on Fedora.

== Feedback ==
We don't have any feedback at this time from the community.

Upstream is enthusiastic and supportive of us enabling this in Fedora.

== Benefit to Fedora ==

This change improves the coverage of Fedora packages on aarch64. .NET
Core was previously only available on x86_64; it's now available on
aarch64 as well. Users who are using Fedora on aarch64 can now use the
normal distribution packages for .NET Core, instead of having to find,
download an installing .NET Core some other way. As a result of this,
Fedora becomes a more attractive target for developing and deploying
applications on aarch64.

== Scope ==
* Proposal owners:

# Will update .NET Core to bootstrap and build on aarch64 (along with
x86_64). This shouldn't affect any other packages.
# Will work with package owners of packages that .NET Core depends on
if those specific dependencies of .NET Core are broken, buggy or
un-available on aarch64

* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (checked with #fedora-releng)
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
There is no known impact on upgrades.

.NET Core was just not available Fedora for aarch64 in previous
releases of Fedora. It will be available in Fedora starting Fedora 33.

.NET Core is not a dependency of any other package, so users running
Fedora on aarch64 and then upgrading from Fedora 32 to 33 will not
automatically pull it in. They will have to install it manually.

== How To Test ==

# Install Fedora 33 on aarch64
# Install .NET Core: sudo dnf install dotnet-sdk-3.1
# Run .NET Core: dotnet --info

The above steps should install .NET Core and show the .NET Core SDK
and Runtime version numbers. There should be no error messages or any
other failures.

== User Experience ==

- Users using Fedora on aarch64 as a platform for .NET Core
development will be able to use the Fedora-provided packages for .NET
Core

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: Proposal owner will revert packaging changes
and switch back to how .NET Core was built in Fedora 32.
* Blocks release? No
* Blocks product? No

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
.NET Core is now available on aarch64! You can install .NET Core on
Fedora on aarch64 using the normal packaging tools: sudo dnf
install dotnet-sdk-3.1


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: Heads up: changing the subject format of change proposal announcements

[Samuel Sieb]

On 7/16/20 1:19 PM, Jonathan Wakely wrote:

On 16/07/20 08:39 +, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 15, 2020 at 11:49:13AM -0700, Samuel Sieb wrote:

On 7/15/20 3:30 AM, Daniel P. Berrangé wrote:
>FCP33: Support PARSEC [Self-Contained]
>FCP33: PostgreSQL 31 [Self-Contained]
>FCP33: Policy for Modules in Fedora and Fedora ELN [Self-Contained]
>FCP33: Golang 1.15 [Late, System-Wide]
>FCP33: X.org Utility Deaggregation [Self-Contained]


"F33: ..." would be even better.


Or "F33 CHANGE: ..."

FCP33 seems a bit cryptic. F33 CHANGE is self-explanatory.


I think the idea is that most people would know what it is or would find 
out pretty quickly.  The objective is to have sufficient information in 
the visible subject area of an email client to be able to identify the 
threads.

___
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 1858048] New: rt-5.0.0 is available

[bugzilla]

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

Bug ID: 1858048
   Summary: rt-5.0.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: rt
  Keywords: FutureFeature, Triaged
  Assignee: rc040...@freenet.de
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, ti...@math.uh.edu
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 5.0.0
Current version/release in rawhide: 4.4.4-5.fc33
URL: http://bestpractical.com/request-tracker/

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


-- 
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 1858048] rt-5.0.0 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
The following Sources of the specfile are not valid URLs so we cannot
automatically build the new version for you.  Please use URLs in your Source
declarations if possible.

- README.tests
- rt.conf.in
- README.fedora.in
- rt.logrotate.in


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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2020-07-17 from 21:00:00 to 22:00:00 UTC
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9722/

___
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: Problems with yum update

[warron.french]

Actually the file indicates DEFAULT already.

--
Warron French



On Thu, Jul 16, 2020 at 4:12 PM Kevin Fenzi  wrote:

> On Thu, Jul 16, 2020 at 03:59:23PM -0400, warron.french wrote:
> > I work in a lab environment that has a proxy somewhere on the network.
> >
> > I have my VMware VM running CentOS8 and have installed the
> > epel-latest-release package.
> snip...
> >
> > I don't know what to do to fix this.  Can someone please explain what the
> > problem is on a high level and then what to do about it so that I can
> learn
> > from this?
>
> What does:
>
> cat /etc/crypto-policies/state/current
>
> show?
>
> If it's FUTURE, thats the problem. You can do back to default with:
>
> sudo update-crypto-policies --set DEFAULT
>
> kevin
> ___
> 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 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: Heads up: changing the subject format of change proposal announcements

[Jonathan Wakely]

On 16/07/20 08:39 +, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 15, 2020 at 11:49:13AM -0700, Samuel Sieb wrote:

On 7/15/20 3:30 AM, Daniel P. Berrangé wrote:
>FCP33: Support PARSEC [Self-Contained]
>FCP33: PostgreSQL 31 [Self-Contained]
>FCP33: Policy for Modules in Fedora and Fedora ELN [Self-Contained]
>FCP33: Golang 1.15 [Late, System-Wide]
>FCP33: X.org Utility Deaggregation [Self-Contained]


"F33: ..." would be even better.


Or "F33 CHANGE: ..."

FCP33 seems a bit cryptic. F33 CHANGE is self-explanatory.

___
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: Problems with yum update

[Kevin Fenzi]

On Thu, Jul 16, 2020 at 03:59:23PM -0400, warron.french wrote:
> I work in a lab environment that has a proxy somewhere on the network.
> 
> I have my VMware VM running CentOS8 and have installed the
> epel-latest-release package.
snip...
> 
> I don't know what to do to fix this.  Can someone please explain what the
> problem is on a high level and then what to do about it so that I can learn
> from this?

What does: 

cat /etc/crypto-policies/state/current

show?

If it's FUTURE, thats the problem. You can do back to default with: 

sudo update-crypto-policies --set DEFAULT

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

[EPEL-devel] Problems with yum update

[warron.french]

I work in a lab environment that has a proxy somewhere on the network.

I have my VMware VM running CentOS8 and have installed the
epel-latest-release package.

When I execute a generic *yum update *I run into problems.  They are here:
[root@wsf-owt-dev001:yum.repos.d]# yum update Extra Packages for Enterprise
Linux 8 - Playground - x86_64 0.0 B/s | 0 B 00:01 Errors during downloading
metadata for repository 'epel-playground': - Curl error (60): Peer
certificate cannot be authenticated with given CA certificates for
https://mirrors.fedoraproject.org/metalink?repo=playground-epel8=x86_64=stock=centos
[SSL certificate problem: EE certificate key too weak] Error: Failed to
download metadata for repo 'epel-playground': Cannot prepare internal
mirrorlist: Curl error (60): Peer certificate cannot be authenticated with
given CA certificates for
https://mirrors.fedoraproject.org/metalink?repo=playground-epel8=x86_64=stock=centos
[SSL certificate problem: EE certificate key too weak]

I see the curl error, so I try a curl command and also run into problems:
[root@wsf-owt-dev001:yum.repos.d]# curl -v
https://mirrors.fedoraproject.org/metalink?repo=playground-epel8=x86_64=stock=centos
[1] 683465 [2] 683466 [3] 683467 [root@wsf-owt-dev001:yum.repos.d]# * Uses
proxy env variable https_proxy == 'http://214.3.129.49:80' * Trying
214.3.129.49... * TCP_NODELAY set * Connected to 214.3.129.49
(214.3.129.49) port 80 (#0) * allocate connect buffer! * Establish HTTP
proxy tunnel to mirrors.fedoraproject.org:443 > CONNECT
mirrors.fedoraproject.org:443 HTTP/1.1 > Host: mirrors.fedoraproject.org:443
> User-Agent: curl/7.61.1 > Proxy-Connection: Keep-Alive > < HTTP/1.0 200
Connection established < * Proxy replied 200 to CONNECT request * CONNECT
phase completed! * ALPN, offering h2 * ALPN, offering http/1.1 *
successfully set certificate verify locations: * CAfile:
/etc/pki/tls/certs/ca-bundle.crt CApath: none * TLSv1.3 (OUT), TLS
handshake, Client hello (1): * CONNECT phase completed! * CONNECT phase
completed! * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN),
TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS alert, bad
certificate (554): * SSL certificate problem: EE certificate key too weak *
Closing connection 0 curl: (60) SSL certificate problem: EE certificate key
too weak More details here: https://curl.haxx.se/docs/sslcerts.html curl
failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above. [1] Exit 60 curl
-v https://mirrors.fedoraproject.org/metalink?repo=playground-epel8 [2]-
Done arch=x86_64 [3]+ Done infra=stock

I don't know what to do to fix this.  Can someone please explain what the
problem is on a high level and then what to do about it so that I can learn
from this?

Thank you,
--
Warron French
___
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: memory testing

[Michael Catanzaro]

On Wed, Jul 15, 2020 at 4:05 pm, Chris Murphy  
wrote:

I haven't. It might be useful to know what Michael Catanzaro thinks of
it, before he goes off to buy and install ECC RAM!


I've been running it since last night and it hasn't turned up any 
problems. Very tricky. :/


___
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: memory testing

[Peter Jones]

On Wed, Jul 15, 2020 at 01:17:50PM -0600, Chris Murphy wrote:
> On Wed, Jul 15, 2020 at 12:49 PM Solomon Peachy  wrote:
> >
> > On Wed, Jul 15, 2020 at 01:41:27PM -0500, Michael Catanzaro wrote:
> > > Note: memtest86+ actually had an upstream release recently after a *very*
> > > long hiatus, so I guess it's no longer dead. But I agree memtest86+ should
> > > be dropped, since it's incompatible with UEFI and surely not what we want
> > > people to try using.
> >
> > Yes and no -- having it available on the fedora installer media is quite
> > useful, and since that's going to have to support dual BIOS/UEFI
> > booting, there's not really any downside.
> 
> The same binary can't support both firmware types. As far as I know,
> only the proprietary version offers a UEFI binary. And long ago the
> plan for the free version was not to have dual support, but to
> eventually deprecate the BIOS tester and only offer a UEFI binary.

If someone decided they wanted to spend some time making memtest86+ work
as an EFI binary, I'd be happy to mentor them.  I think getting it to
the point where it can test everything except the RAM UEFI is actually
/using/ is probably a medium difficulty but not huge project.  It's been
waaay down on my todo list forever, and I've got some ideas about how to
go about it, just not the time to do it myself.

> But another difficulty even if there will be a free UEFI memtest86+ is
> that it would need to be signed for UEFI Secure Boot, same as shim and
> the kernel (and kernel modules). Seems like its own burden.

If we had a UEFI memory tester, you could reasonably add a boot entry
for shim with memtest.efi as the optional loader data (like we do for
fwupd) and enroll it in MoK with something like:

pesign -i memtest.efi -P -h | while read name hash ; do
mokutil --import-hash ${hash}
done

There's not a super *huge* benefit to actually signing it, since you're
sure to be rebooting when you need to use it anyway.

-- 
Peter
___
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: Anyone using Tiled windows on Plasma out there ?

[John Florian]

On 2020-07-16 13:59, Sergio Belkin wrote:
>
>
> El jue., 16 jul. 2020 a las 12:22, John Florian
> (mailto:jflor...@doubledog.org>>) escribió:
>
> In any case, the few hassles I encounter are so much less time
> demanding
> than all the window management I manually did before adopting
> kwin-tiling.  If I could only have "focus follows eyes", I'd be quite
> happy in the WM serving me rather than the other way around.  :-)
>
>
> John Florian
>
>
> LoL
> I have set "focus follows mouse"
Same here; it's the next best thing.
> Actually what I find most useful is an hybrid approach. I mean, tiled
> windows, but sometimes I need to focus on only one windows and to
> maximize it :)
I too do this now and then and kwin-tiling is really good at allowing
this as well as allowing me to resize the windows for a temporary override.
> -- 
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.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
___
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: Anyone using Tiled windows on Plasma out there ?

[Sergio Belkin]

El jue., 16 jul. 2020 a las 12:22, John Florian ()
escribió:

> In any case, the few hassles I encounter are so much less time demanding
> than all the window management I manually did before adopting
> kwin-tiling.  If I could only have "focus follows eyes", I'd be quite
> happy in the WM serving me rather than the other way around.  :-)
>
>
> John Florian
>

LoL
I have set "focus follows mouse"
Actually what I find most useful is an hybrid approach. I mean, tiled
windows, but sometimes I need to focus on only one windows and to maximize
it :)
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.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

Fedora in 6th gear

[Zbigniew Jędrzejewski-Szmek]

In the FESCo meeting summary email sent out today there were 10
changes approved. I had the feeling that this is more than usual,
so I took a look at the wiki.

Tally (systemd-wide and self-contained):
F20: 14 + 22
F21: 28 + 34
F22: 21 + 15
F23: 12 +  7
F24: 20 + 23
F25:  9 + 11
F26: 17 + 22
F27: 20 + 15
F28: 31 + 19
F29: 23 + 20
F30: 25 + 24
F31: 21 + 21
F32: 23 + 20
F33: 40 + 18 (and growing)

Seems that this be a busy release :)

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

Claim delve

[Alejandro Saez Morollon]

Hi there, folks.

Delve[0] (a Golang debugger) was retired due to the impossibility of
building a new version of delve for dependencies issues. I would like
to claim the package and fix the situation. I already have one of the
dependencies[1] in the works.

I already talked with the original maintainer (he's in cc) and he is OK with it.

Thanks.

[0] https://src.fedoraproject.org/rpms/delve
[1] https://src.fedoraproject.org/rpms/golang-starlark
___
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: Building kernel rpms with KASAN enabled

[stan via devel]

On Thu, 16 Jul 2020 11:02:02 -0400
Steve Grubb  wrote:
 
> What is the best way to build an official Fedora kernel SRPM with
> KASAN=y?

This is the official documentation for building a custom kernel.

https://fedoraproject.org/wiki/Building_a_custom_kernel

It might already be set in the stock Fedora kernel.  You could go into
/boot and run
grep -i kasan on one of the configuration files.  All my kernels are
custom builds, so I can't check the stock setting, but mine have it
turned on.

I use rpmbuild because I've been building custom kernels from the
srpm for a long time, but that is now deprecated in favor of fedpkg or
mock, I think.

If you want to run a custom kernel in uefi secure mode, you will have
to generate a local key pair, and sign the custom kernel with pesign.
If you don't have the rh-test-cert installed in the efi key database,
you will have to remove it from the kernel binary using pesign, as well,
or it won't be found on boot.
___
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

Summary/Minutes from yesterday's FESCo Meeting (2020-07-15) + additional approved tickets

[Zbigniew Jędrzejewski-Szmek]

= Yesterday's Meeting =

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-15/fesco.2020-07-15-14.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-15/fesco.2020-07-15-14.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-15/fesco.2020-07-15-14.00.log.html

Meeting summary
---
* init process  (zbyszek, 14:00:22)

* #2429 F33 System-Wide Change: Make btrfs the default file system for
  desktop variants  (zbyszek, 14:03:54)
  * LINK:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED_status=ON_DEV_status=ON_QA_status=VERIFIED_status=RELEASE_PENDING=Fedora=kernel=OP=OP=product=component=alias=short_desc=status_whiteboard=CP=CP=OR_id=11221750=substring=substring=substring=substring=substring=Fedora_format=advanced_desc=btrfs_desc_type=allwordssubstr=btrfs=btrfs=btrfs=btrfs=btrfs
(zbyszek, 14:12:49)
  * LINK: https://github.com/rhinstaller/anaconda/pull/2728
(King_InuYasha, 14:34:25)
  * AGREED: APPROVED (+8, 0, -1)  (zbyszek, 14:35:39)

* #2441 F34 System-Wide Change: RPM-level auto release and changelog
  bumping  (zbyszek, 14:37:33)
  * AGREED: We'll continue the discussion in the ticket and on the
mailing list and return to this next week (+6, 0, 0)  (zbyszek,
14:43:40)

* #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros -
  Detached rpm changelogs  (zbyszek, 14:44:17)
  * We'll continue the discussion in the ticket and on the mailing list
and return to this next week  (zbyszek, 14:46:54)

* #2445 Proposal: Make the "shortcut" decision process require a
  specific request and assent  (zbyszek, 14:47:04)
  * ACTION: bcotton to adjust the PR based on discussion  (zbyszek,
15:01:20)

* Next week's chair  (zbyszek, 15:01:36)
  * ACTION: ignatenkobrain will chair next meeting  (zbyszek, 15:01:54)

* Open Floor  (zbyszek, 15:02:01)
  * LINK:

https://fedoraproject.org/wiki/Infrastructure/2020-post-datacenter-move-known-issues
(nirik, 15:03:54)

Meeting ended at 15:10:16 UTC.


Action Items

* bcotton to adjust the PR based on discussion
* ignatenkobrain will chair next meeting


= Discussed and Voted in the Ticket (2nd batch) =

#2435 F33 Self-Contained Change: Enable EarlyOOM on Fedora KDE
https://pagure.io/fesco/issue/2435
APPROVED (+6,0,-0)

#2436 F33 System-Wide Change: OpenLDAP without Non-threaded Libraries
https://pagure.io/fesco/issue/2436
APPROVED (+6,0,-0)

#2438 F33 Self-Contained Change: Make the unversioned %{__python} macro error 
by default
https://pagure.io/fesco/issue/2438
APPROVED (+6,0,-0)

#2439 F33 System-Wide Change: IBus 1.5.23
https://pagure.io/fesco/issue/2439
APPROVED (+4,0,-0) as a self-contained change.

#2442 F33 System-Wide Change: Introduce Storage Instantiation Daemon
https://pagure.io/fesco/issue/2442
APPROVED (+4,1,-0) as a self-contained change.



On Wed, Jul 15, 2020 at 06:44:56AM +, Zbigniew Jędrzejewski-Szmek wrote:
> = Discussed and Voted in the Ticket =
> 
> #2431 F33 System-Wide Change: Cleanup GNOME Hidden Boot Menu Integration
> https://pagure.io/fesco/issue/2431
> APPROVED (+7, 0, 0)
> 
> #2432 F33 System-Wide Change: NetworkManager keyfile instead of ifcfg-rh
> https://pagure.io/fesco/issue/2432
> APPROVED (+5, 0, 0)
> 
> #2433 F33 System-Wide Change: Disable dmraid-activation.service on first run 
> if no dmraid sets are found
> https://pagure.io/fesco/issue/2433
> APPROVED (+6, 0, 0)
> 
> #2434 F33 System-Wide Change: Remove device-mapper-multipath from the Fedora 
> workstation livecd
> https://pagure.io/fesco/issue/2434
> APPROVED (+7, 0, 0)
> 
> Please note that there's a bunch of tickets which are close to
> approval, but for which the one-week voting period ends in the
> afternoon today. In the very likely case that they are approved, I'll
> include their announcement in today's meeting summary.
___
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: Anyone using Tiled windows on Plasma out there ?

[Franco Comida]

Il mar 14 lug 2020, 22:35 Robbie Harwood  ha scritto:

> Sergio Belkin  writes:
>
> > What is the better option to to get tiled windows in Plasma?
> >
> > I've tried a few kwin scripts with no luck, for example:
> >
> > - Grid-Tiling
> > - Krohnkite
> > - Tiling Extension
> >
> > The best I've tried so far is the last one, but can be too unstable...
> >
> > What is your experience about it?
>
> I've not tried (not a KDE user), but wanted to offer that it might be
> easier to swap out the window manager completely completely rather than
> using a script/extension.  KDE 4 + 5 look to have provisions for this by
> making a script that does `export KDEWM=/path/to/your/wm` [1].
>
> Thanks,
> --Robbie
>
> 1:
> https://wiki.haskell.org/Xmonad/Using_xmonad_in_KDE#Make_xmonad_your_window_manager_in_KDE
>

Another tutorial can be found here:

https://userbase.kde.org/Tutorials/Using_Other_Window_Managers_with_Plasma/en


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

Re: Non-responsive maintainer: jujens

[Miro Hrončok]

On 16. 07. 20 18:37, Fabian Affolter wrote:

Hi all,

In the past few weeks I tried to get in touch with Julien Enselme
(jujens) with no luck. No responses to Bugzilla comments, NEEDINFO flags
and direct e-mails.

Some of his packages are out-dated and now start to block the upgrade of
other packages.

I've also filed the requisite non-responsive maintainer check bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1857849

Does anyone know how to get in touch with him?


I've contacted Julian wrt https://fedoraproject.org/wiki/Changes/DeprecatePytoml

My email to them went on 2020-06-19, the reply came on 2020-06-25.

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

libupnp soname bump

[Gwyn Ciesla via devel]

I will soon update libupnp to 1.12.1, which is a soname change. This impacts:
gerbera
gmediarender
linphone
These all build fine with the new release, and I'll rebuild them.

-G

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

Sent with ProtonMail Secure Email.

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

Non-responsive maintainer: jujens

[Fabian Affolter]

Hi all,

In the past few weeks I tried to get in touch with Julien Enselme
(jujens) with no luck. No responses to Bugzilla comments, NEEDINFO flags
and direct e-mails.

Some of his packages are out-dated and now start to block the upgrade of
other packages.

I've also filed the requisite non-responsive maintainer check bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1857849

Does anyone know how to get in touch with him?

Kind regards,

Fabian



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

[EPEL-devel] Gnome 2 for EPEL8

[Orion Poplawski]

Anyone interested in maintaining some Gnome 2 libraries (at least 
libgnomeui and deps) in EPEL8?  I might if no one else is as someone at 
work needs it, but I'm hoping that someone with more Gnome experience 
would be willing.


Thanks.


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



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Anyone using Tiled windows on Plasma out there ?

[John Florian]

On 2020-07-14 19:29, Sergio Belkin wrote:
> Yup, AFAIK  "Tiling Extension" is
> https://github.com/kwin-scripts/kwin-tiling. In fact, I think is the
> best option available, but it happens sometimes on non-weekend days
> that it becomes buggy and unstable, and it's pain, kwin crashes, I
> have to use openbox, to recover it the session control, but I think
> that is when I open Thunderbird for my job...

I have not experienced such crashes.  What I do encounter now and then
is the compositor being disabled due to it crashing and kwin-tiling very
much depends on the compositor.  My $HOME is mounted via NFS on several
workstations of various hardware quality.  Some have Nvidia and that
seems to be where most of my problems are.

My only other complaint is trying to move a separate chromium-browser
window into another so as to merge tabs.  That gets a little weird
because things seem confused as to whether I wish to make this one
browser window the new master or merge it into the master.  What I've
found works rather reliably is to make the window that's to receive the
tab the master and then drag the other tab into its tab bar.

In any case, the few hassles I encounter are so much less time demanding
than all the window management I manually did before adopting
kwin-tiling.  If I could only have "focus follows eyes", I'd be quite
happy in the WM serving me rather than the other way around.  :-)


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

Building kernel rpms with KASAN enabled

[Steve Grubb]

Hello,

What is the best way to build an official Fedora kernel SRPM with KASAN=y?

TIA,
-Steve

___
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 1857787] New: perl-LWP-Protocol-https-6.09 is available

[bugzilla]

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

Bug ID: 1857787
   Summary: perl-LWP-Protocol-https-6.09 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-LWP-Protocol-https
  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: 6.09
Current version/release in rawhide: 6.07-11.fc33
URL: http://search.cpan.org/dist/LWP-Protocol-https/

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


-- 
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: Orphaning repsnapper, gtkglextmm

[Miro Hrončok]

On 15. 07. 20 11:29, Miro Hrončok wrote:

On 02. 06. 20 22:36, Miro Hrončok wrote:
I've just orphaned repsnapper and gtkglextmm. repsnapper depends on gtkglextmm 
which depends on pangox-compat, which is already orphaned for 4 weeks.


I haven't touched the packages in years and I don't use repsnapper.

In case a new maintainer emerges, I can stay around if needed.


The packages were now retired.

As a result, I've also orphaned amftools, rapidxml and I am working towards 
transitioning lmfit to @junghans or orphaning if they are not interested.


I've also orphaned stbi which I've packaged 7 years ago for amftools and never 
updated.


--
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: Orphaning repsnapper, gtkglextmm

[Miro Hrončok]

On 16. 07. 20 9:17, Iñaki Ucar wrote:

On Wed, 15 Jul 2020 at 11:39, Miro Hrončok  wrote:


On 02. 06. 20 22:36, Miro Hrončok wrote:

I've just orphaned repsnapper and gtkglextmm. repsnapper depends on gtkglextmm
which depends on pangox-compat, which is already orphaned for 4 weeks.

I haven't touched the packages in years and I don't use repsnapper.

In case a new maintainer emerges, I can stay around if needed.


The packages were now retired.

As a result, I've also orphaned amftools, rapidxml and I am working towards
transitioning lmfit to @junghans or orphaning if they are not interested.


I took rapidxml.


Thanks!

--
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: Searching a new home for my packages

[Nikola Forró]

On Sat, 2020-06-13 at 13:54 +0200, Thomas Spura wrote:
> Any takers for:
> - *python-mglob* and/or *python-minimock *(instead of retiring it?)
> - *scipy* (seems to be mostly maintained by Orion/Miro now)

I can take scipy (FAS: nforro).

Thanks,
Nikola
___
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: memory testing

[Kamil Paral]

On Wed, Jul 15, 2020 at 10:56 PM Przemek Klosowski via devel <
devel@lists.fedoraproject.org> wrote:

> Have you looked at memtester? What do you think of it?
>

I've successfully used memtester in the past to detect suspend-resume
memory corruption on my desktop, just by periodically suspending and
resuming the PC while memtester was running. It helped me to confirm that
that particular desktop really has some memory corruption issues (while
other PCs I tested on didn't). So in this particular case I was satisfied
with the tool.

The downside is that it's a userspace utility, so it can't test the whole
memory. When I e.g. purchase a new RAM stick, I prefer to boot into
memtest86+ (I switch to BIOS mode to be able to boot it) and test the whole
stick with it. Anything running inside an OS can't provide you with the
same level of verification.
___
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: memory testing

[Vitaly Zaitsev via devel]

On 15.07.2020 21:17, Chris Murphy wrote:
> Does anyone know if Microsoft has a signed UEFI memory tester?

Yes, but it requires Windows Native API in order to work.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

> Simply put, "no". Debian and Ubuntu ".deb" packages too often don't
> follow the File System Hierarchy, they may have different layouts and
> package naming capitalization schemes for matching Fedora packagers
> like "PyYAML", they may have overlapping pre-set uids and mismatched
> group name conventions, etc., etc, and the grub intigration for new
> kernels is likely to be a nightmare. It would be a full-time job for
> several competent engineers to do that kind of package impedance
> matching.

I'm not interested in debating Debian and derivatives packaging
guidelines, but I generally prefer how Fedora does things (except
notably, modularity).

> Just. no.aot abd deb inside a "podman" baswed container? Maybe?
> But it seems not worth the pain.

The whole point of this change was to allow working with DPKG tooling
without leaving the comfort zone of Fedora, without forcing a VM or
container indirection. And trust me on this one, I do not inflict
Debian packaging on myself by choice so I'm really keen on not adding
any needless step, to the point where before submitting this change I
had my own homebrew apt package. As a bonus point, this change also
retired apt-rpm which had been dead and unmaintained for a decade, and
according to the upstream developer himself it had unfixed security
issues.

So apt-rpm needed to go anyway, and there was no reason not to replace
it with regular apt (apt-rpm would otherwise conflict with apt). And
by the way, even though I initiated this change I later lost my
ability to implement it, but it's been done since f32 thanks to Neal
Gompa and Sérgio Basto.

I hope it clarifies what was actually implemented.

Dridi
___
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-java] Re: Mass rebuild for f33-java11 side tag completed

[Mat Booth]

On Wed, 15 Jul 2020 at 16:54, Mat Booth  wrote:
>
> On Mon, 13 Jul 2020 at 19:14, Jiri Vanek  wrote:
> >
> > >
> > > A cursory glance shows that some failed with network problems. E.g.
plexus-velocity failed with this:
> > >
> > > DEBUG util.py:621:  Errors during downloading metadata for repository
'build':
> > > DEBUG util.py:621:- Curl error (18): Transferred a partial file
for
> > >
http://kojipkgs-cache01.s390.fedoraproject.org/repos/f33-java11/1710873/s390x/repodata/d901882654dc717c8fc91a6b2f018eeaa538eb6e003b0927bc9ae85895a83786-filelists.xml.gz
> > > [transfer closed with 23617146 bytes remaining to read]
> > >
> > > (Sigh, flakey s390x machines, we meet again.)
> > >
> > > When I retriggered the build it succeeded:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1540681
> > >
> > > Might be worth a retry of other failures before filing FTBFS bugs.
> >
> > Thanx!
> >
> > Will elaborate on this!
>
> Any update? Any thoughts on when you want to merge the f33-java11 side
tag back into rawhide?
>

BTW There are some packages, e.g. built by ant with no sauce/target level
specified at all, that are built with Java 11-level bytecode.

This is bad because if there is a dependent package that requires Java 8
for some reason it won't work because the bytecode of one your dependencies
is too new and cannot be interpreted by Java 8. In these cases

I am fixing such occurrences in the ```f33-java11``` build target as I
encounter them -- just something to be aware of in case you see any
UnsupportedClassVersionErrors.

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

Re: Heads up: changing the subject format of change proposal announcements

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 15, 2020 at 11:49:13AM -0700, Samuel Sieb wrote:
> On 7/15/20 3:30 AM, Daniel P. Berrangé wrote:
> >FCP33: Support PARSEC [Self-Contained]
> >FCP33: PostgreSQL 31 [Self-Contained]
> >FCP33: Policy for Modules in Fedora and Fedora ELN [Self-Contained]
> >FCP33: Golang 1.15 [Late, System-Wide]
> >FCP33: X.org Utility Deaggregation [Self-Contained]

"F33: ..." would be even better.

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: Firefox 78.0.2 for F32

[Felix Schwarz]

Just wanted to mention that the F31 update needs one more karma so it can be
pushed to stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-dd4e4e78ef

Maybe a F31 user can take a look?

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

Re: Orphaning repsnapper, gtkglextmm

[Iñaki Ucar]

On Wed, 15 Jul 2020 at 11:39, Miro Hrončok  wrote:
>
> On 02. 06. 20 22:36, Miro Hrončok wrote:
> > I've just orphaned repsnapper and gtkglextmm. repsnapper depends on 
> > gtkglextmm
> > which depends on pangox-compat, which is already orphaned for 4 weeks.
> >
> > I haven't touched the packages in years and I don't use repsnapper.
> >
> > In case a new maintainer emerges, I can stay around if needed.
>
> The packages were now retired.
>
> As a result, I've also orphaned amftools, rapidxml and I am working towards
> transitioning lmfit to @junghans or orphaning if they are not interested.

I took rapidxml.

-- 
Iñaki Úcar
___
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