[Bug 1738385] New: Request mod_perl package for EPEL 8

[bugzilla]

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

Bug ID: 1738385
   Summary: Request mod_perl package for EPEL 8
   Product: Fedora EPEL
   Version: epel7
Status: NEW
 Component: mod_perl
  Assignee: ppi...@redhat.com
  Reporter: yoshida.ryui...@bsearchtech.com
QA Contact: extras...@fedoraproject.org
CC: jkal...@redhat.com, jor...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Description of problem:

Request for mod_perl to be included in EPEL 8.


Our product depends on mod_perl. 
We completed testing with RHEL 8.0 beta which included mod_perl.

However, mod_perl was removed from the official RHEL 8.0 release. 
It is still not included in RHEL 8.1 beta.

Thus we have been postponing RHEL8 support.

mod_perl in EPEL 8 will be greatly appreciated.

This post is in response to the announcement below.
https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/KXMMLYSAXAVHDKFFBVEFYYZHPJBWXOQQ/

-- 
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 6 updates-testing report

[updates]

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

atop-1.27-3.el6
bird-1.6.7-1.el6
perl-Net-BGP-0.17-1.el6

Details about builds:



 atop-1.27-3.el6 (FEDORA-EPEL-2019-9070cc2d90)
 An advanced interactive monitor to view the load on system and process level

Update Information:

Logrotate fix.

ChangeLog:

* Tue Aug  6 2019 Gwyn Ciesla  - 1.27-2
- Logrotate fix.

References:

  [ 1 ] Bug #1737782 - Logrotate for atop will stop working on 2020
https://bugzilla.redhat.com/show_bug.cgi?id=1737782




 bird-1.6.7-1.el6 (FEDORA-EPEL-2019-73632e7689)
 BIRD Internet Routing Daemon

Update Information:

BIRD 1.6.7 (2019-08-01) ===* BFD: Support for VRFs   *
Several bugfixes

ChangeLog:

* Mon Aug  5 2019 Robert Scheck  - 1.6.7-1
- Upgrade to 1.6.7




 perl-Net-BGP-0.17-1.el6 (FEDORA-EPEL-2019-0bb53334b5)
 Perl module for object-oriented API to the BGP protocol

Update Information:

Net::BGP 0.17 =- Fixed bug where the wrong aggregator variable
was being tested.   - Added an "OpaqueData" parameter and equivalent accessor
sub `opaque_data()` to allow for the storage of arbitrary data with the
peer. The main purpose of this is to allow the user to store extra data (a
scalar or ref) with the peer that is then readable by the call back
routines. I realise there are other ways to do this, but this seems much
cleaner.   - Fixes the situation where a socket is still in the list of sockets
to be selected on, yet it has been closed. I believe this is caused when we
create a new connection to a peer at the same time as we receive one. When
we find ourselves with a bad FD, we re-check the list of sockets to select
on.   - It is possible to receive a notification message (error) in response to
an OPEN message (e.g. an unrecognised ASN). We were getting a Finite State
Machine error, now we call the notification callback.   - `_kill_session()` will
call `_close_session()` even if the socket is not open. This will finally
terminate the session properly (stops some weird loops).   - Added extra members
of the notification state engine. Now calls `_kill_session()` rather than
`_cease()` when the peer socket is closed.

ChangeLog:

* Tue Aug  6 2019 Robert Scheck  0.17-1
- Upgrade to 0.17 (#1737397)
* Fri Jul 26 2019 Fedora Release Engineering  - 0.16-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Fri May 31 2019 Jitka Plesnikova  - 0.16-3
- Perl 5.30 rebuild

References:

  [ 1 ] Bug #1737397 - Upgrade perl-Net-BGP to 0.17
https://bugzilla.redhat.com/show_bug.cgi?id=1737397


___
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

[updates]

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

BackupPC-4.3.1-2.el8
BackupPC-XS-0.59-3.el8
bird-2.0.5-1.el8
earlyoom-1.3-3.el8
flameshot-0.6.0-4.el8
git-secret-0.2.6-2.el8
git-subrepo-0.4.0-3.el8
google-benchmark-1.5.0-2.el8
guidelines-support-library-1.0.0-4.el8
json-3.6.1-2.el8
json11-1.0.0-3.el8
libolm-3.1.3-1.el8
lmdbxx-0.9.14.1-4.20160229git0b43ca8.el8
maddy-1.1.0-2.el8
mpark-variant-1.4.0-2.el8
mustache-3.2.1-2.el8
perl-Net-BGP-0.17-1.el8
purple-hangouts-0-65.20190607hg3f7d89b.el8
purple-skypeweb-1.5-6.20190520git5d29285.el8
python-emoji-0.5.1-3.el8
python-pytelegrambotapi-3.6.6-3.el8
range-v3-0.5.0-2.el8
rlottie-0-3.20190707git0a43020.el8
robin-map-0.6.1-2.el8
rsync-bpc-3.1.2.0-3.el8
singularity-3.3.0-1.el8
tweeny-3-3.el8

Details about builds:



 BackupPC-4.3.1-2.el8 (FEDORA-EPEL-2019-cb63a0bac5)
 High-performance backup system

Update Information:

Initial build for EPEL 8.




 BackupPC-XS-0.59-3.el8 (FEDORA-EPEL-2019-cb63a0bac5)
 Implementation of various BackupPC functions in a perl-callable module

Update Information:

Initial build for EPEL 8.




 bird-2.0.5-1.el8 (FEDORA-EPEL-2019-bae459fc5e)
 BIRD Internet Routing Daemon

Update Information:

BIRD 2.0.5 (2019-08-01) ===* OSPF Graceful restart (RFC
3623, RFC 5187)   * BGP: Dynamic BGP   * BGP: Promiscuous ASN mode   * BGP:
Mandatory option for channels   * BFD: Support for VRFs   * Graceful restart
command   * Redesigned filtering code   * Many bugfixes  Notes: Previous version
introduced an error in handling of OSPF NSSA-LSA, causing compatibility issues
with proper implementations. The error is fixed in this version, therefore there
are compatibility issues in OSPF NSSA areas between this and previous version.

ChangeLog:

* Mon Aug  5 2019 Robert Scheck  - 2.0.5-1
- Upgrade to 2.0.5
* Wed Jul 24 2019 Fedora Release Engineering  - 
2.0.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild




 earlyoom-1.3-3.el8 (FEDORA-EPEL-2019-94f489d1c7)
 Early OOM Daemon for Linux

Update Information:

First portion of Fedora packages built for EPEL8.




 flameshot-0.6.0-4.el8 (FEDORA-EPEL-2019-94f489d1c7)
 Powerful and simple to use screenshot software

Update Information:

First portion of Fedora packages built for EPEL8.




 git-secret-0.2.6-2.el8 (FEDORA-EPEL-2019-2261827101)
 A bash-tool to store your private data inside a git repository

Update Information:

Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild




 git-subrepo-0.4.0-3.el8 (FEDORA-EPEL-2019-94f489d1c7)
 Git Submodule Alternative

Update Information:

First portion of Fedora packages built for EPEL8.




 google-benchmark-1.5.0-2.el8 (FEDORA-EPEL-2019-94f489d1c7)
 A microbenchmark support library

Update Information:

First portion of Fedora packages built for EPEL8.

[389-devel] 389 DS nightly 2019-08-07 - 93% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/07/report-389-ds-base-1.4.1.6-20190806git4159cf6.fc30.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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 357  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 132  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294   
cinnamon-3.6.7-5.el7
  98  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
  96  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  68  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fc63c75ab1   
hostapd-2.8-1.el7
  33  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12067fc897   
dosbox-0.74.3-2.el7
  25  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-487a6fb279   
knot-2.8.2-1.el7 knot-resolver-4.1.0-1.el7
  25  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aabd063c30   
squirrelmail-1.4.23-1.el7.20190710
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ef655ec55e   
proftpd-1.3.5e-5.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-44d26d23ea   
upx-3.95-4.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b6948289f0   
pdns-4.1.11-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ad7b11b384   
igraph-0.7.1-12.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-643d621522   
jhead-3.03-4.el7


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

bird-1.6.7-1.el7
boinc-client-7.16.1-2.el7
git-secret-0.2.6-2.el7
perl-Net-BGP-0.17-1.el7
purple-discord-0-25.20190805git250a8a0.el7
purple-hangouts-0-65.20190607hg3f7d89b.el7
python-django-1.11.23-1.el7
python-plumbum-1.6.7-2.el7
qdigidoc-4.2.2-4.el7

Details about builds:



 bird-1.6.7-1.el7 (FEDORA-EPEL-2019-9657484745)
 BIRD Internet Routing Daemon

Update Information:

BIRD 1.6.7 (2019-08-01) ===* BFD: Support for VRFs   *
Several bugfixes

ChangeLog:

* Mon Aug  5 2019 Robert Scheck  - 1.6.7-1
- Upgrade to 1.6.7




 boinc-client-7.16.1-2.el7 (FEDORA-EPEL-2019-f641534c73)
 The BOINC client

Update Information:

7.16.1 release    7.16.1 release

ChangeLog:

* Tue Aug  6 2019 Germano Massullo 
- replaced %setup -q -n boinc-%{gittag_custom} with %autosetup -n 
boinc-%{gittag_custom}
* Tue Aug  6 2019 Germano Massullo  - 7.16.1-1
- 7.16.1 release
- Removed scheduler.patch tray_icon_removal.patch window_close.patch because 
they have been merged into 7.16.1
* Wed Jul 24 2019 Fedora Release Engineering  - 
7.14.2-18
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild




 git-secret-0.2.6-2.el7 (FEDORA-EPEL-2019-5578d0c2fa)
 A bash-tool to store your private data inside a git repository

Update Information:

Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild




 perl-Net-BGP-0.17-1.el7 (FEDORA-EPEL-2019-f267faa772)
 Perl module for object-oriented API to the BGP protocol

Update Information:

Net::BGP 0.17 =- Fixed bug where the wrong aggregator variable
was being tested.   - Added an "OpaqueData" parameter and equivalent accessor
sub `opaque_data()` to allow for the storage of arbitrary data with the
peer. The main purpose of this is to allow the user to store extra data (a
scalar or ref) with the peer that is then readable by the call back
routines. I realise there are other ways to do this, but this seems much
cleaner.   - Fixes the situation where a socket is still in the list of sockets
to be selected on, yet it has been closed. I believe this is caused when we
create a new connection to a peer at the same time as we receive one. When
we find ourselves with a bad FD, we re-check the list of sockets to select
on.   - It is possible to receive a notification message (error) in response to
an OPEN message (e.g. an unrecognised ASN). We were getting a Finite State
Machine error, now we call the notification callback.   - 

Re: Fedora-Rawhide-20190806.n.0 compose check report

[Adam Williamson]

On Tue, 2019-08-06 at 11:52 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Compose FAILS proposed Rawhide gating check!
> 13 of 45 required tests failed, 8 results missing
> openQA tests matching unsatisfied gating requirements shown with **GATING** 
> below
> Unsatisfied gating requirements that could not be mapped to openQA tests:
> FAILED: compose.cloud.all
> 
> Failed openQA tests: 40/147 (x86_64), 1/2 (arm)

Most of the problems here boil down to SELinux issues:

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

that are causing quite a lot of havoc. Both ought to be addressed with
the next compose, so we'll see where we are when that lands.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?

[Daniel Walsh]

On 8/6/19 9:15 AM, Jun Aruga wrote:
>>> Please come!
>>>
>> Would love to see your examples use podman...
> Sorry here is the podman's example.
> And no worry. podman's examples are used as much as possible in my talk!
>
> ```
> $ uname -m
> x86_64
>
> $ podman run --rm -t arm64v8/fedora:30 uname -m
> standard_init_linux.go:211: exec user process caused "exec format error"
>
> $ sudo podman run --rm --privileged multiarch/qemu-user-static --reset -p yes
>
> $ podman run --rm -t arm64v8/fedora:30 uname -m
> aarch64
> ```
>
Nice.
___
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: NeuroFedora review swap: python-SALib

[Ankur Sinha]

On Tue, Aug 06, 2019 11:35:44 +0200, Tomas Korbar wrote:
> Hi,
> I could take this review. I hope you do not mind that i do not have package in
> need of review.

Not at all, please proceed :)

-- 
Thanks very much,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: fedora-review seam to not work 8-(

[Robert-André Mauchin]

On Tuesday, 6 August 2019 05:47:58 CEST J. Scheurich wrote:
> > What's your version of fedora-review? You should have 0.7.2
> >
> >
> >
> > Name : fedora-review
> > Version  : 0.7.2
> > Release  : 1.fc30
> 
> $ fedora-review -V
> fedora-review version 0.7.2 65d36bb 2019-04-09 16:30:26 -0400
> external plugins:
> $ yum info fedora-review
> ...
> Installed Packages
> Name : fedora-review
> Version  : 0.7.2
> Release  : 2.fc31
> Architecture : noarch
> Size : 626 k
> Source   : fedora-review-0.7.2-2.fc31.src.rpm
> 
> This seams to be release 2.fc31, not 1.fc30.
> 
> Should i try to install 1.fc30 ?
> 

No they're the same. I ran f-r 0.7.2 on your SPEC and SRPM with no issue, so I 
don't know çrom where the error is coming. Try cleaning your chroot.

mock -scrub=all

___
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-review seam to not work 8-(

[Kevin Kofler]

Vitaly Zaitsev via devel wrote:
> Most of modern C++ header-only libraries provides Cmake scripts. Such
> scripts will be installed to %{_libdir}/cmake/foo. That's why they
> cannot be noarch.

CMake will actually also find the scripts if you install them to 
%{_datadir}/cmake/foo. And if (and ONLY if) there is nothing
architecture-dependent in them, that is exactly where they belong. 
Unfortunately, the only package other than CMake itself that I see using 
this on my system is bash-completion.

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

[HEADS-UP]: Mercurial with Python3 on rawhide?

[Petr Stodulka]

Hi guys,
as discussion was started week ago, Python2 is dying. As that, some
dependencies of mercurial will be orphaned soon (or they are already)
and mercurial as it is has to move in weeks on Python3. As I wrote
in [0], I already started some testing and investigation.

Currently it seems that with ugly hacky fix, we are able to run
somi-working mercurial with Python3. I did just simple testing
that worked for me and in the latest copr-build (below), it seems
that hgk extension is workin as well. But many of you extensions
will be probably broken. So, I guess the most probably mercurial
will be broken for the others who use it.

So it's question, should I rebase it in rawhide and setup for Python3
already even when it is so broken, or should I wait several weeks yet
for additional fixes?

If anyone is interested about testing before it will be done,
just try:
  # dnf copr enable pstodulk/mercurial
- it's just first attempt.

Here is the list of RPMs depending on mercurial:
git-cinnabar
gitifyhg
git-remote-hg
gwsmhg
hg-git
hgsvn
hgview-common
python2-anyvc
python2-wstool
python3-hgapi
python3-wstool
qct-mercurial
rabbitvcs-core
rbm
tortoisehg
trac-mercurial-plugin


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

[EPEL-devel] Re: how to use epel8-playground?

[Stephen John Smoogen]

On Tue, 6 Aug 2019 at 15:10, Dave Dykstra  wrote:

> I don't think I understand how epel8-playground is envisioned to be
> used.  I did the fedpkg request-branch epel8 and got it created for my
> package.  I also ran fedpkg request-branch epel8-playground as in the
> script below, but that was rejected:
> Could not execute request_branch: You cannot directly request
> epel8-playground branch, as they are created as part of epel branch requests
>
>
An epel8-playground branch should have been created when the epel8 one was
done. This means something broke when the original package branch was
requested. What was the package(s)? so I can track down what is broken?



> However, the epel8 branch got created, and in git there was a
> package.cfg containing "targets = epel8 epel8-playground".  With that I
> was able to do "fedpkg build --target epel8-playground", but there is no
> epel8-playground git branch, and in fact if I try to create one and push
> it to the server it gets rejected
> remote: Unspecified ref refs/heads/epel8-playground is blocked
> ...
>   ! [remote rejected] HEAD -> epel8-playground (pre-receive hook
> declined)
> So apparently epel8-playground has to share the epel8 git branch, and
> you can build it in koji, but I don't understand what the value is in
> that.  How is that different than building it for the epel8 koji target,
> as long as you don't request that it get put into the testing yum
> repository?
>
> Dave
>
> On Thu, Aug 01, 2019 at 01:33:55PM -0400, Stephen John Smoogen wrote:
> > Subject: Re: [EPEL-devel] EPEL-8 package requests are now open
> > I would like to thank everyone for their patience and for the people who
> > have put in a lot of work to get us to where we can start building
> > packages. The following is a general outline of what we have for
> packaging
> > procedures for EPEL-8. The master document is currently at
> > https://hackmd.io/@ssmoogen/B1p2QM-eS  It will be stored with other EPEL
> > documents shortly.
> >
> > # EPEL-8 Packaging Procedures
> >
> > ## Introduction
> >
> > When a new Red Hat Enterprise Linux occurs, one of the steps to get EPEL
> > going for it is branching of various packages into new namespace. The
> EPEL
> > Steering Committee does not mass branch all existing packages into the
> > namespace because it has caused multiple problems:
> > 1. The package maintainers did not want to support the package in the
> newer
> > version of EPEL. Package maintainers may only want to support certain
> > versions of Enterprise Linux or may want to wait until their favourite
> > derivative appears.
> > 2. The package does not work in the latest version of RHEL. With multiple
> > years between releases, software which worked on Fedora 18 which would
> > branch to EPEL-7 may not exist anymore with Fedora 28 and EPEL-8 would
> need
> > a completely different version.
> >
> > ## Consumer request for packages
> >
> > People who are interested in getting packages into EPEL should contact
> the
> > package maintainer through [bugzilla](https://bugzilla.redhat.com/ ).
> This
> > allows for the requests to be tracked and if the primary maintainer is
> not
> > interested in branching to EPEL, other ones can step in and do so.
> >
> > ## EPEL Playground
> >
> > We have added an additional set of channels for EPEL-8 called playground.
> > It is meant to be sort of like Fedora Rawhide so that packagers can work
> on
> > versions of software which are too fast moving or will have large API
> > changes from what they are putting in the regular channel.
> >
> > To try and make this transparent, we have made it so when a package is
> > built in epel8 it will normally also be built in epel8-playground. This
> is
> > done via a packages.cfg file which lists the targets for fedpkg to build
> > against. A successful package build will then go through 2 different
> paths:
> > * epel8 package will go into bodhi to be put into epel8-testing
> > * epel8-playground will bypass bodhi and go directly into
> epel8-playground
> > the next compose.
> >
> > If a packager needs to focus only on epel8 or epel8-playground they can
> > edit packages.cfg to change the ```target= epel8 epel8-playground``` to
> > ```target= epel8 ```.
> >
> > Packages in epel8-playground are primarily to be used in the following
> > manner:
> >
> > * To test out some new version of the package that might not be stable
> yet.
> > * To test out some new packaging of the package
> > * To test a major version change of the package that they want to land at
> > the next epel8 minor release.
> > * To build a package that will never be stable enough for epel8, but
> still
> > could be useful to some.
> > * At minor RHEL releases (ie, 8.1, 8.2) people can pull in big changes
> from
> > playground to the main epel8 packages. Since people will be upgrading and
> > paying more attention than usual anyhow at those points, it's a great
> > chance to do that change, but also you want to make sure it's 

[EPEL-devel] how to use epel8-playground?

[Dave Dykstra]

I don't think I understand how epel8-playground is envisioned to be
used.  I did the fedpkg request-branch epel8 and got it created for my
package.  I also ran fedpkg request-branch epel8-playground as in the
script below, but that was rejected:
Could not execute request_branch: You cannot directly request 
epel8-playground branch, as they are created as part of epel branch requests

However, the epel8 branch got created, and in git there was a
package.cfg containing "targets = epel8 epel8-playground".  With that I
was able to do "fedpkg build --target epel8-playground", but there is no
epel8-playground git branch, and in fact if I try to create one and push
it to the server it gets rejected
remote: Unspecified ref refs/heads/epel8-playground is blocked
...
  ! [remote rejected] HEAD -> epel8-playground (pre-receive hook declined)
So apparently epel8-playground has to share the epel8 git branch, and
you can build it in koji, but I don't understand what the value is in
that.  How is that different than building it for the epel8 koji target,
as long as you don't request that it get put into the testing yum
repository?

Dave

On Thu, Aug 01, 2019 at 01:33:55PM -0400, Stephen John Smoogen wrote:
> Subject: Re: [EPEL-devel] EPEL-8 package requests are now open
> I would like to thank everyone for their patience and for the people who
> have put in a lot of work to get us to where we can start building
> packages. The following is a general outline of what we have for packaging
> procedures for EPEL-8. The master document is currently at
> https://hackmd.io/@ssmoogen/B1p2QM-eS  It will be stored with other EPEL
> documents shortly.
> 
> # EPEL-8 Packaging Procedures
> 
> ## Introduction
> 
> When a new Red Hat Enterprise Linux occurs, one of the steps to get EPEL
> going for it is branching of various packages into new namespace. The EPEL
> Steering Committee does not mass branch all existing packages into the
> namespace because it has caused multiple problems:
> 1. The package maintainers did not want to support the package in the newer
> version of EPEL. Package maintainers may only want to support certain
> versions of Enterprise Linux or may want to wait until their favourite
> derivative appears.
> 2. The package does not work in the latest version of RHEL. With multiple
> years between releases, software which worked on Fedora 18 which would
> branch to EPEL-7 may not exist anymore with Fedora 28 and EPEL-8 would need
> a completely different version.
> 
> ## Consumer request for packages
> 
> People who are interested in getting packages into EPEL should contact the
> package maintainer through [bugzilla](https://bugzilla.redhat.com/ ). This
> allows for the requests to be tracked and if the primary maintainer is not
> interested in branching to EPEL, other ones can step in and do so.
> 
> ## EPEL Playground
> 
> We have added an additional set of channels for EPEL-8 called playground.
> It is meant to be sort of like Fedora Rawhide so that packagers can work on
> versions of software which are too fast moving or will have large API
> changes from what they are putting in the regular channel.
> 
> To try and make this transparent, we have made it so when a package is
> built in epel8 it will normally also be built in epel8-playground. This is
> done via a packages.cfg file which lists the targets for fedpkg to build
> against. A successful package build will then go through 2 different paths:
> * epel8 package will go into bodhi to be put into epel8-testing
> * epel8-playground will bypass bodhi and go directly into epel8-playground
> the next compose.
> 
> If a packager needs to focus only on epel8 or epel8-playground they can
> edit packages.cfg to change the ```target= epel8 epel8-playground``` to
> ```target= epel8 ```.
> 
> Packages in epel8-playground are primarily to be used in the following
> manner:
> 
> * To test out some new version of the package that might not be stable yet.
> * To test out some new packaging of the package
> * To test a major version change of the package that they want to land at
> the next epel8 minor release.
> * To build a package that will never be stable enough for epel8, but still
> could be useful to some.
> * At minor RHEL releases (ie, 8.1, 8.2) people can pull in big changes from
> playground to the main epel8 packages. Since people will be upgrading and
> paying more attention than usual anyhow at those points, it's a great
> chance to do that change, but also you want to make sure it's panned out,
> so you can test before hand in playground.
> 
> Consumers should be aware that packages in EPEL8-playground are there
> without any Service Level Expectations. You may want to only cherry pick
> packages from there as needed.
> 
> ## Developer request for branching multiple packages
> 
> Branching is handled the same way as requesting a branch using `fedpkg
> request-branch`. A maintainer can request an epel8 branch using `fedpkg
> request-branch 

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

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2019-08-07 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. Agenda is in the 
https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next 


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

___
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 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

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



--- Comment #12 from errata-xmlrpc  ---
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2019:2097 https://access.redhat.com/errata/RHSA-2019:2097

-- 
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 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

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

errata-xmlrpc  changed:

   What|Removed |Added

External Bug ID||Red Hat Product Errata
   ||RHSA-2019:2097



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

Could not execute clone: [Errno 2] No such file or directory: '/home/mcatanzaro/Projects/fedora-scm/eog/.git/info/exclude'

[mcatanzaro]

$ fedpkg clone eog
Cloning into 'eog'...
remote: Counting objects: 2048, done.
remote: Compressing objects: 100% (1594/1594), done.
remote: Total 2048 (delta 787), reused 1036 (delta 349)
Receiving objects: 100% (2048/2048), 253.53 KiB | 2.33 MiB/s, done.
Resolving deltas: 100% (787/787), done.
Could not execute clone: [Errno 2] No such file or directory: 
'/home/mcatanzaro/Projects/fedora-scm/eog/.git/info/exclude'


The clone actually succeeds. I've been seeing this error for weeks now. 
What's going on?


___
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: I wish to drop python2-Cython

[Robbie Harwood]

Miro Hrončok  writes:

> I'd like to drop python2-Cython subpackage from Cython, as I consider
> it not needed, however there are still packages that buildrequire
> it. Let me know if you want to maintain python2-Cython instead of me
> and Igor.

Hi, I believe you're CC'd on the thread with myself and the offlineimap
maintainers.  To recap: offlineimap is currently python2-only and uses
python-gssapi.  At your suggestion, I'm planning to provide
python2-gssapi for fc31, and will stop doing so in rawhide once fc31 has
branched.  If you are intending to remove python2-Cython before then, I
think we need to revisit that plan.

Thanks,
--Robbie


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

I wish to drop python2-Cython

[Miro Hrončok]

I'd like to drop python2-Cython subpackage from Cython, as I consider it not 
needed, however there are still packages that buildrequire it. Let me know if 
you want to maintain python2-Cython instead of me and Igor.


python2-Cython is buildrequired by:

bzr
pystatgrab
python-cassandra-driver
python-gssapi

cassandra - already doesn't install
https://bugzilla.redhat.com/show_bug.cgi?id=1737649

python-lxml
dep removed in https://src.fedoraproject.org/rpms/python-lxml/pull-request/2

python-mistune
dep removed in https://src.fedoraproject.org/rpms/python-mistune/pull-request/2

eclipse-pydev
unused build dep
attempted removal previously closed
https://src.fedoraproject.org/rpms/eclipse-pydev/pull-request/1


I'm CCing the maintainers of directly dependent packages.

There are possibly more indirectly dependent packages that need bzr, gssapi, 
etc. The Python ones are pictured at: https://fedora.portingdb.xyz/pkg/Cython/
under "Dependency Tree". Biggest tree is under python-lxml , but the dependency 
on python2-Cython is easily removed there.


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

Re: Fedora rawhide compose report: 20190806.n.0 changes

[Fabio Valentini]

On Tue, Aug 6, 2019, 15:26 Fedora Rawhide Report 
wrote:

> OLD: Fedora-Rawhide-20190805.n.0
> NEW: Fedora-Rawhide-20190806.n.0
>
> = SUMMARY =
> Added images:0
> Dropped images:  0
> Added packages:  5
> Dropped packages:2
> Upgraded packages:   94
> Downgraded packages: 1
>
> Size of added packages:  1.67 MiB
> Size of dropped packages:647.12 KiB
> Size of upgraded packages:   2.09 GiB
> Size of downgraded packages: 21.21 KiB
>
> Size change of upgraded packages:   -38.52 MiB
> Size change of downgraded packages: -299 B
>
> = ADDED IMAGES =
>
> = DROPPED IMAGES =
>
> = ADDED PACKAGES =
> Package: libtickit-0.3.2-1.fc31
> Summary: Terminal Interface Construction Kit
> RPMs:libtickit libtickit-devel
> Size:1.38 MiB
>
> Package: perl-Module-Package-RDF-0.014-1.fc31
> Summary: Drive your distribution with RDF
> RPMs:perl-Module-Package-RDF
> Size:29.91 KiB
>
> Package: perl-Test2-Harness-0.001080-1.fc31
> Summary: Test2 Harness designed for the Test2 event system
> RPMs:perl-Test2-Harness
> Size:211.32 KiB
>
> Package: perl-XRD-Parser-0.201-1.fc31
> Summary: Parse XRD and host-meta files into RDF::Trine models
> RPMs:perl-XRD-Parser
> Size:31.58 KiB
>
> Package: python-plette-0.2.2-1.fc31
> Summary: Python library which contains Pipfile parser
> RPMs:python3-plette
> Size:27.81 KiB
>
>
> = DROPPED PACKAGES =
> Package: crda-3.18_2019.03.01-1.fc31
> Summary: Regulatory compliance daemon for 802.11 wireless networking
> RPMs:crda crda-devel
> Size:553.00 KiB
>
> Package: mingw-python-enum34-1.1.6-3.fc31
> Summary: MinGW Windows Python enum34
> RPMs:mingw32-python2-enum34 mingw64-python2-enum34
> Size:94.12 KiB
>
>
> = UPGRADED PACKAGES =
> Package:  LibRaw-0.19.4-1.fc31
> Old package:  LibRaw-0.19.3-2.fc31
> Summary:  Library for reading RAW files obtained from digital photo
> cameras
> RPMs: LibRaw LibRaw-devel LibRaw-samples LibRaw-static
> Size: 4.50 MiB
> Size change:  1.21 KiB
> Changelog:
>   * Mon Aug 05 2019 Gwyn Ciesla  - 0.19.4-1
>   - 0.19.4
>
>
> Package:  babeld-1.9.0-1.fc31
> Old package:  babeld-1.8.5-1.fc31
> Summary:  Ad-hoc network routing daemon
> RPMs: babeld
> Size: 587.56 KiB
> Size change:  -1.51 KiB
> Changelog:
>   * Mon Aug 05 2019 Gwyn Ciesla  - 1.9.0-1
>   - 1.9.0
>
>
> Package:  bash-5.0.7-3.fc31
> Old package:  bash-5.0.7-2.fc31
> Summary:  The GNU Bourne Again shell
> RPMs: bash bash-devel bash-doc
> Size: 17.95 MiB
> Size change:  10.81 KiB
> Changelog:
>   * Fri Aug 02 2019 Kamil Dudka  - 5.0.7-3
>   - Sanitize public header file 
> Resolves: #1736676
>
>
> Package:  beaker-26.5-1.fc31
> Old package:  beaker-26.3-2.fc30
> Summary:  Full-stack software and hardware integration testing system
> RPMs: beaker-client beaker-common
> Size: 263.89 KiB
> Size change:  -97.98 KiB
> Changelog:
>   * Sun Mar 31 2019 Greg Hellings  - 26.4-1
>   - Upstream version 26.4
>
>   * Tue Jul 16 2019 Greg Hellings  - 26.5-1
>   - Upstream version 26.5
>
>
> Package:  binutils-2.32-21.fc31
> Old package:  binutils-2.32-20.fc31
> Summary:  A GNU collection of binary utilities
> RPMs: binutils binutils-devel binutils-gold
> Size: 44.22 MiB
> Size change:  8.91 KiB
> Changelog:
>   * Mon Aug 05 2019 Nick Clifton   - 2.32-21
>   - Stop strip from complaining if the first build note is not a version
> note.  (#1736114)
>
>
> Package:  bird-2.0.5-1.fc31
> Old package:  bird-2.0.4-2.fc31
> Summary:  BIRD Internet Routing Daemon
> RPMs: bird bird-doc
> Size: 3.30 MiB
> Size change:  25.32 KiB
> Changelog:
>   * Mon Aug 05 2019 Robert Scheck  - 2.0.5-1
>   - Upgrade to 2.0.5
>
>
> Package:  conda-4.7.10-1.fc31
> Old package:  conda-4.7.2-1.fc31
> Summary:  Cross-platform, Python-agnostic binary package manager
> RPMs: conda python3-conda
> Size: 854.17 KiB
> Size change:  -79.11 KiB
> Changelog:
>   * Wed Jul 24 2019 Fedora Release Engineering 
> - 4.7.2-2
>   - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
>
>   * Mon Jul 29 2019 Zbigniew Jędrzejewski-Szmek  -
> 4.7.6-1
>   - Update to latest version (#1678578)
>
>   * Wed Jul 31 2019 Orion Poplawski  - 4.7.10-1
>   - Update to 4.7.10
>
>   * Sat Aug 03 2019 Zbigniew Jędrzejewski-Szmek  -
> 4.7.10-1
>   - Fix 'conda shell.* hook' invocations (#1737165)
>
>
> Pac

Re: Intention to retire Release Notes RPM

[Stephen Gallagher]

On Tue, Aug 6, 2019 at 4:58 AM Martin Kolman  wrote:

> On Mon, 2019-08-05 at 20:44 -0400, Neal Gompa wrote:
> > On Mon, Aug 5, 2019 at 8:43 PM Martin Kolman  wrote:
> > > On Sat, 2019-08-03 at 03:45 -0400, Neal Gompa wrote:
> > > > On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd
> > > >  wrote:
> > > > > Hi All,
> > > > >
> > > > > Barring objection, I plan to retire the release notes package from
> > > > > Fedora on or after August 9, 2019.  The package has not been
> updated
> > > > > since F28.  Despite the fact that we have literally shipped a
> package
> > > > > containing the F28 release notes in F29 and F30, there have been no
> > > > > comments.  This has been discussed with the docs team and is
> > > > > supported.  I am not aware of any dependencies and I believe it was
> > > > > removed from release criteria in F29.
> > > > >
> > > > > I will run `fedpkg retire` and further request removal via
> > > > >
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=fedora-obsolete-packages
> > > > >
> > > > > Please reply on list if you have any questions or concerns.
> > > > >
> > > >
> > > > Does Anaconda not support showing the release notes _anywhere_? That
> > > > was the original impetus for shipping it that way...
> > > There is currently no screen in either graphical or text interface of
> Anaconda that would show Fedora release notes.
> >
> > Aside from it being mildly depressing that there's no way to discover
> > the release notes for a Fedora release, I guess it's fine to retire.
> > We don't have any other entry points in the distribution for viewing
> > the release notes anymore...
> At least for the online release notes, aren't they somewhere on the
> default landing page in Firefox after initial Fedora
> installation ? I seem to remember something like that.
>

Yes, the landing page has a prominent link to "Fedora Documentation", which
links to a page for individual release documentation which in turn has the
release notes. It's not a simple one-click, but it's fairly discoverable.
___
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/retiring 3 Java packages

[D L]

Perhaps, if this introduction is done by video conference it could be recorded 
and archived for future reference on this page – 
   https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/
If its not too much trouble.

--
Danny Lee  
I have been impressed with the urgency of doing. Knowing is not enough; we must 
apply. Being willing is not enough; we must do.  ~ Leonardo da Vinci

From: Marián Konček
Sent: Tuesday, August 6, 2019 6:20 AM
To: devel@lists.fedoraproject.org
Cc: p...@barkhof.uni-bremen.de
Subject: Re: Orphaning/retiring 3 Java packages

I could introduce Peter into Fedora java packaging.

On 24. 7. 2019 20:03, Peter Boy wrote:
>
>> Am 23.07.2019 um 16:08 schrieb Mikolaj Izdebski :
>>
>> On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok  wrote:
>>> On 23. 07. 19 13:27, Mikolaj Izdebski wrote:
 Soon after Fedora 31 branching I intend to retire java-packaging-howto
 package and orphan byaccj and javapackages-tools packages. The reason
 is that I intend to maintain these packages as part of modules.

 I will continue to maintain non-modular packages through lifecycles of
 Fedora 29-31, but starting from Fedora 32 I will maintain modular
 versions only.
>>> Do you realize that while your decision to move essential bits of Java 
>>> packaging
>>> to modules might untie your hands a lot, it is causing everybody else 
>>> involved
>>> more and more trouble?
>> Perhaps I don't realize the trouble, could you elaborate? I expect
>> orphaned packages to be adopted by someone, likely a member of
>> Stewardship SIG. These two packages are low-maintenance and don't
>> require much work - they don't have many upstream changes and don't
>> get many bugs reported. So I don't see that much trouble in this case.
>>
>>> I acknowledge that it is your right to orphan essentially anything you want,
>>> however the motivation here seems a bit... nonempathetic.
>>>
>>> Would you mind to reconsider?
>> Definitely - this is the reason I wrote to the list. Do you have any
>> proposal what to do with these packages instead of orphaning them?
>
> Sorry for jumping in. I think this might be an opportunity to participate in 
> the Fedora Projekt. I’ve a lot of experience in java development and in 
> creating application rpms, but none in the specialties of Fedora packaging. 
> Would you accept me as co-maintainer and provide some guidance at the 
> beginning?
>
>
>
> Peter
>
>
>
>
>> --
>> Mikolaj Izdebski
>> ___
>> 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
> —
> Dr. Peter Boy
> Universität Bremen
> Mary-Sommerville-Str. 5
> 28359 Bremen
> Germany
>
> p...@zes.uni-bremen.de
> www.zes.uni-bremen.de
>
> 
>
> Are you looking for a web content management system for scientific research 
> organizations?
> Have a look at http://www.scientificcms.org
>
>
> Are you looking for a web content management system for public 
> administrations?
> Have a look at http://www.aplaws.org & https://fedorahosted.org/aplaws/
>   
> ___
> 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

-- 

Marián Konček
___
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: Fedora 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module

[Stephen Gallagher]

On Tue, Aug 6, 2019 at 8:58 AM Matus Honek  wrote:

> Hello Stephen,
>
> I've made changes according to your notes [1], please have a look. And
> thanks for the feedback!
>
> [1]
> https://fedoraproject.org/w/index.php?title=Changes%2FOpenLDAPwithBerkleyDBasModule=revision=549672=549258
>
>
Looks good. Thank you.
___
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: I wish to drop python2-Cython

[Fabio Valentini]

On Tue, Aug 6, 2019, 15:17 Miro Hrončok  wrote:

> On 06. 08. 19 14:13, Mat Booth wrote:
> >
> > On Tue, 6 Aug 2019 at 13:11, Miro Hrončok  > > wrote:
> >
> > On 06. 08. 19 14:07, Mat Booth wrote:
> >  > eclipse-pydev
> >  > unused build dep
> >  > attempted removal previously closed
> >  > https://src.fedoraproject.org/rpms/eclipse-pydev/pull-request/1
> >  >
> >  >
> >  > I already told you it was *NOT* unused -- that there was a
> packaging bug.
> > And I
> >  > fixed this bug in a later commit:
> >  >
> >
> https://src.fedoraproject.org/rpms/eclipse-pydev/c/4f70b5b54f220e9d0f624397ec22883091782d7c?branch=eclipse
> >  >
> >  > Please try again with latest eclipse-pydev update from
> > updates-testing-modular
> >
> > Apologies, I was checking master. I'm extremely not used to "see if
> there is a
> > modular fork of a package" process.
> >
> > In master, this is still the case.
> >
> >
> > Eclipse will be shipping in modules only from F31.
>

If that's the case, do you plan to retire the packages in non-modular
branches? Right now, they're all broken, and "pollute" dependency queries
(this also affects the Stewardship SIG).

Fabio


> Note that we are removing Python 2 packages based on data from Fedora
> Rawhide,
> because that is the only thing that can be done with reasonable effort.
>
> If a modular only package depends on Python 2 package, it will not prevent
> our
> queries to recognize is as a leaf package and drop it.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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: Where are armv7hl, i686 and ppc64le Container tar.xz files?

[Jun Aruga]

> > Please come!
> >
> Would love to see your examples use podman...

Sorry here is the podman's example.
And no worry. podman's examples are used as much as possible in my talk!

```
$ uname -m
x86_64

$ podman run --rm -t arm64v8/fedora:30 uname -m
standard_init_linux.go:211: exec user process caused "exec format error"

$ sudo podman run --rm --privileged multiarch/qemu-user-static --reset -p yes

$ podman run --rm -t arm64v8/fedora:30 uname -m
aarch64
```

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

Re: Fedora 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module

[Matus Honek]

Hello Stephen,

I've made changes according to your notes [1], please have a look. And
thanks for the feedback!

[1] 
https://fedoraproject.org/w/index.php?title=Changes%2FOpenLDAPwithBerkleyDBasModule=revision=549672=549258

On Thu, Aug 1, 2019 at 1:49 PM Stephen Gallagher  wrote:
>
> On Thu, Aug 1, 2019 at 6:57 AM Matus Honek  wrote:
> >
> > On Wed, Jul 31, 2019 at 4:57 PM Stephen Gallagher  
> > wrote:
> > >
> > > On Tue, Jul 23, 2019 at 8:45 AM Ben Cotton  wrote:
> > > >
> > > > https://fedoraproject.org/wiki/Changes/OpenLDAPwithBerkleyDBasModule
> > > >
> > > > == Summary ==
> > > > Change the ''openldap-servers'' package so that BDB and HDB backends
> > > > are required to be dynamically loaded.
> > > >
> > > > == Owner ==
> > > > * Name: [[User:mhonek| Matus Honek]]
> > > > * Email: mhonek (at) redhat (dot) com
> > > >
> > >
> > > ...
> > >
> > > > == Upgrade/compatibility impact ==
> > > > Server using BDB or HDB backends without modified configuration would
> > > > fail to start. See ''User Experience'' section for more information.
> > > >
> > >
> > > Is this avoidable or do you consider it desirable? Is there any harm
> > > in shipping a default configuration that does the loadmodule for both
> > > deprecated backends?
> >
> > The default configuration is shipped only when the package is newly
> > installed. Given the BDB/HDB should not be used there is no point in
> > pre-loading these in new instalments.
> >
>
> Understood.
>
> > >
> > > My guess here is that you want this to be an explicit breakage to help
> > > users learn that the backend is no longer supported. If that's the
> > > case, I'd like to see that spelled out in the Change.
> >
> > Correct. I thought this was put clearly but I sure can improve this.
> > Would be spelling this in Detailed Description section acceptable?
>
> Yes, please.
>
> >
> > >
> > > Do any tools exist to simplify the conversion to MDB? Can this be 
> > > automated?
> >
> > I am not aware of any such tools. Numerous demands on upstream were
> > always responded with more-or-less what I put in the section
> > describing the conversion. If any errors are encountered during the
> > process they need to be understood and then fixed manually.
> >
> > Automatic conversion would be far from trivial (and possibly
> > load-intensive depending on sizes). There are two types of
> > configuration (plaintext and "the more complicated one"). A server may
> > have several instances of backends. Each backend type has its own
> > configuration specifics (MDB being easier but still a "human guess"
> > should be made to configure the expected size of it). Not rarely users
> > put configuration into various locations which are not guessable
> > automatically at all. Additionally, users should ideally see the
> > possible errors during the process of conversion and verify the data
> > has not broken.
> >
> > One relatively simple thing to provide would be a pre-run script that
> > would disallow running the slapd's systemd service if the
> > configuration contains BDB/HDB instances and the moduleload is not
> > present, writing into journal clearly what happened and what needs to
> > be done.
> >
>
> This would be highly desirable. It would go a long way towards helping
> users understand the transition. Including a web link in the journal
> message to a detailed conversion HOWTO would be ideal.
>
> > This is not to give reasons not to automate the process, rather
> > explain that understanding and thought needs to go into each
> > instalment's conversion(s).
>
> Sure, makes sense. Thank you for clarifying.



-- 
Matúš Honěk
Software Engineer
Red Hat Czech
___
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 31 release-blocking deliverables

[Ben Cotton]

The list of release-blocking deliverables for Fedora 31 is now
available[1]. If there are any changes that should be made that were
part of an already-accepted Fedora 31 Change proposal, please let me
know. If an edit is required that was not part of an accepted Change
proposal, please file a FESCo ticket[2].

Please note that this is the first time we have used an
announcement-based model instead of a poll-based model for blockers as
approved by FESCo[3]. I am open to your suggestions on timing and
format for this in future releases.

[1] https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
[2] https://pagure.io/fesco/new_issue
[3] https://pagure.io/fesco/issue/2108

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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: Where are armv7hl, i686 and ppc64le Container tar.xz files?

[Daniel Walsh]

On 8/6/19 7:56 AM, Jun Aruga wrote:
>> ```
>> $ docker run --rm -t arm64v8/fedora:30 uname -m
> standard_init_linux.go:207: exec user process caused "no such file or 
> directory"
>> $ docker run --rm --privileged multiarch/qemu-user-static:register --reset
>> $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m
>> aarch64
> Recently our multiarch project released a new feature to enable to run
> a standard multi-architecture containers on x86_64, without
> multiarch/* container that was needed before, not depending on host OS
> environment.
>
> That means below workflow works
>
> ```
> $ uname -m
> x86_64
>
> $ docker run --rm -t arm64v8/ubuntu uname -m
> standard_init_linux.go:211: exec user process caused "exec format error"
>
> $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
>
> $ docker run --rm -t arm64v8/fedora:30 uname -m
> aarch64
> ```
>
> Is it fine to advertise my talk at Flock 2019 this Friday here? :)
>
> Title: Let's add Fedora multiarch containers to your CI.
> https://flock2019.sched.com/event/SJLx/lets-add-fedora-multiarch-containers-to-your-ci
>
> * When: Friday August 9, 2019 10:30 - 10:55
> * Where: the room Panorama (140m² / 40 people), The Danubius Hotel
> HELIA in Budapest, Hungary, at Flock Budapest 2019
>
> = Table of contents = (it might be changed a little bit later)
> * Fedora and Upstream - Past and Present
> * CPU Architecture Kinds
> * Tools for multiarch - Today's topics
> * QEMU and binfmt_misc - on News
> * 5 steps - to add Fedora multiarch to upstream CI
> * 1. qemu-$arch-static - An interpreter
> * 2. binfmt_misc - A kernel feature for binary format
> * 3. qemu-user-static RPM on Fedora
> * 4. qemu-user-static RPM and container
> * 5. multiarch/qemu-user-static image and CI
> * Note A: ARM supported CI services
> * Note B: A Dockerfile to multi-arch images
>   docker buildx, docker/(podman) build --platform
>
> Please come!
>
Would love to see your examples use podman...
___
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 31 release-blocking deliverables

[Ben Cotton]

The list of release-blocking deliverables for Fedora 31 is now
available[1]. If there are any changes that should be made that were
part of an already-accepted Fedora 31 Change proposal, please let me
know. If an edit is required that was not part of an accepted Change
proposal, please file a FESCo ticket[2].

Please note that this is the first time we have used an
announcement-based model instead of a poll-based model for blockers as
approved by FESCo[3]. I am open to your suggestions on timing and
format for this in future releases.

[1] https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
[2] https://pagure.io/fesco/new_issue
[3] https://pagure.io/fesco/issue/2108

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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

Fedora rawhide compose report: 20190806.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190805.n.0
NEW: Fedora-Rawhide-20190806.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  5
Dropped packages:2
Upgraded packages:   94
Downgraded packages: 1

Size of added packages:  1.67 MiB
Size of dropped packages:647.12 KiB
Size of upgraded packages:   2.09 GiB
Size of downgraded packages: 21.21 KiB

Size change of upgraded packages:   -38.52 MiB
Size change of downgraded packages: -299 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: libtickit-0.3.2-1.fc31
Summary: Terminal Interface Construction Kit
RPMs:libtickit libtickit-devel
Size:1.38 MiB

Package: perl-Module-Package-RDF-0.014-1.fc31
Summary: Drive your distribution with RDF
RPMs:perl-Module-Package-RDF
Size:29.91 KiB

Package: perl-Test2-Harness-0.001080-1.fc31
Summary: Test2 Harness designed for the Test2 event system
RPMs:perl-Test2-Harness
Size:211.32 KiB

Package: perl-XRD-Parser-0.201-1.fc31
Summary: Parse XRD and host-meta files into RDF::Trine models
RPMs:perl-XRD-Parser
Size:31.58 KiB

Package: python-plette-0.2.2-1.fc31
Summary: Python library which contains Pipfile parser
RPMs:python3-plette
Size:27.81 KiB


= DROPPED PACKAGES =
Package: crda-3.18_2019.03.01-1.fc31
Summary: Regulatory compliance daemon for 802.11 wireless networking
RPMs:crda crda-devel
Size:553.00 KiB

Package: mingw-python-enum34-1.1.6-3.fc31
Summary: MinGW Windows Python enum34
RPMs:mingw32-python2-enum34 mingw64-python2-enum34
Size:94.12 KiB


= UPGRADED PACKAGES =
Package:  LibRaw-0.19.4-1.fc31
Old package:  LibRaw-0.19.3-2.fc31
Summary:  Library for reading RAW files obtained from digital photo cameras
RPMs: LibRaw LibRaw-devel LibRaw-samples LibRaw-static
Size: 4.50 MiB
Size change:  1.21 KiB
Changelog:
  * Mon Aug 05 2019 Gwyn Ciesla  - 0.19.4-1
  - 0.19.4


Package:  babeld-1.9.0-1.fc31
Old package:  babeld-1.8.5-1.fc31
Summary:  Ad-hoc network routing daemon
RPMs: babeld
Size: 587.56 KiB
Size change:  -1.51 KiB
Changelog:
  * Mon Aug 05 2019 Gwyn Ciesla  - 1.9.0-1
  - 1.9.0


Package:  bash-5.0.7-3.fc31
Old package:  bash-5.0.7-2.fc31
Summary:  The GNU Bourne Again shell
RPMs: bash bash-devel bash-doc
Size: 17.95 MiB
Size change:  10.81 KiB
Changelog:
  * Fri Aug 02 2019 Kamil Dudka  - 5.0.7-3
  - Sanitize public header file 
Resolves: #1736676


Package:  beaker-26.5-1.fc31
Old package:  beaker-26.3-2.fc30
Summary:  Full-stack software and hardware integration testing system
RPMs: beaker-client beaker-common
Size: 263.89 KiB
Size change:  -97.98 KiB
Changelog:
  * Sun Mar 31 2019 Greg Hellings  - 26.4-1
  - Upstream version 26.4

  * Tue Jul 16 2019 Greg Hellings  - 26.5-1
  - Upstream version 26.5


Package:  binutils-2.32-21.fc31
Old package:  binutils-2.32-20.fc31
Summary:  A GNU collection of binary utilities
RPMs: binutils binutils-devel binutils-gold
Size: 44.22 MiB
Size change:  8.91 KiB
Changelog:
  * Mon Aug 05 2019 Nick Clifton   - 2.32-21
  - Stop strip from complaining if the first build note is not a version note.  
(#1736114)


Package:  bird-2.0.5-1.fc31
Old package:  bird-2.0.4-2.fc31
Summary:  BIRD Internet Routing Daemon
RPMs: bird bird-doc
Size: 3.30 MiB
Size change:  25.32 KiB
Changelog:
  * Mon Aug 05 2019 Robert Scheck  - 2.0.5-1
  - Upgrade to 2.0.5


Package:  conda-4.7.10-1.fc31
Old package:  conda-4.7.2-1.fc31
Summary:  Cross-platform, Python-agnostic binary package manager
RPMs: conda python3-conda
Size: 854.17 KiB
Size change:  -79.11 KiB
Changelog:
  * Wed Jul 24 2019 Fedora Release Engineering  - 
4.7.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Mon Jul 29 2019 Zbigniew J??drzejewski-Szmek  - 4.7.6-1
  - Update to latest version (#1678578)

  * Wed Jul 31 2019 Orion Poplawski  - 4.7.10-1
  - Update to 4.7.10

  * Sat Aug 03 2019 Zbigniew J??drzejewski-Szmek  - 4.7.10-1
  - Fix 'conda shell.* hook' invocations (#1737165)


Package:  e2fsprogs-1.45.3-1.fc31
Old package:  e2fsprogs-1.45.2-2.fc31
Summary:  Utilities for managing ext2, ext3, and ext4 file systems
RPMs: e2fsprogs e2fsprogs-devel e2fsprogs-libs e2fsprogs-static e2scrub 
libcom_err libcom_err-devel libss libss-devel
Size: 10.07 MiB
Size change:  -13.61 KiB
Changelog:
  * Thu Jul 25 2019 Lukas Czerner  - 1.45.3-1
  - New upstream release


Package:  evolution-3.33.90-1.fc31
Old package:  evolution-3.33.4-3.fc31
Summary:  Mail and calendar client for GNOME
RPMs: evolution evolution-bogofilter evolution-devel 
evolution-devel-docs evolution-help evolution-langpacks evolution-pst 
evolution-spamassassin
Size: 32.51 MiB
Size change:  -16.59 KiB
Changelog:
  * Mon Aug 05 2019 Milan Crha  - 3.33.90-1
  - Update to 3.33.90


Package

REMINDER: Fedora 31 Code complete (testable) deadline in one week

[Ben Cotton]

According to the Fedora 31 schedule[1], the deadline for Changes to be
code complete (i.e. testable enough for beta) is Tuesday 13 August.
At this time, all Changes should be testable and tracker bugs should
be set to the MODIFIED state. For more information on this deadline,
see the wiki[2].

[1] https://fedorapeople.org/groups/schedule/f-31/f-31-key-tasks.html
[2] 
https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_Completion_deadline

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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

REMINDER: Fedora 31 Code complete (testable) deadline in one week

[Ben Cotton]

According to the Fedora 31 schedule[1], the deadline for Changes to be
code complete (i.e. testable enough for beta) is Tuesday 13 August.
At this time, all Changes should be testable and tracker bugs should
be set to the MODIFIED state. For more information on this deadline,
see the wiki[2].

[1] https://fedorapeople.org/groups/schedule/f-31/f-31-key-tasks.html
[2] 
https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_Completion_deadline

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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

Re: I wish to drop python2-Cython

[Miro Hrončok]

On 06. 08. 19 14:13, Mat Booth wrote:


On Tue, 6 Aug 2019 at 13:11, Miro Hrončok > wrote:


On 06. 08. 19 14:07, Mat Booth wrote:
 >     eclipse-pydev
 >     unused build dep
 >     attempted removal previously closed
 > https://src.fedoraproject.org/rpms/eclipse-pydev/pull-request/1
 >
 >
 > I already told you it was *NOT* unused -- that there was a packaging bug.
And I
 > fixed this bug in a later commit:
 >

https://src.fedoraproject.org/rpms/eclipse-pydev/c/4f70b5b54f220e9d0f624397ec22883091782d7c?branch=eclipse
 >
 > Please try again with latest eclipse-pydev update from
updates-testing-modular

Apologies, I was checking master. I'm extremely not used to "see if there 
is a
modular fork of a package" process.

In master, this is still the case.


Eclipse will be shipping in modules only from F31.


Note that we are removing Python 2 packages based on data from Fedora Rawhide, 
because that is the only thing that can be done with reasonable effort.


If a modular only package depends on Python 2 package, it will not prevent our 
queries to recognize is as a leaf package and drop it.


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

Re: I wish to drop python2-Cython

[Miro Hrončok]

On 06. 08. 19 14:07, Mat Booth wrote:

eclipse-pydev
unused build dep
attempted removal previously closed
https://src.fedoraproject.org/rpms/eclipse-pydev/pull-request/1


I already told you it was *NOT* unused -- that there was a packaging bug. And I 
fixed this bug in a later commit: 
https://src.fedoraproject.org/rpms/eclipse-pydev/c/4f70b5b54f220e9d0f624397ec22883091782d7c?branch=eclipse


Please try again with latest eclipse-pydev update from updates-testing-modular


Apologies, I was checking master. I'm extremely not used to "see if there is a 
modular fork of a package" process.


In master, this is still the case.

--
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: Where are armv7hl, i686 and ppc64le Container tar.xz files?

[Jun Aruga]

> ```
> $ docker run --rm -t arm64v8/fedora:30 uname -m
standard_init_linux.go:207: exec user process caused "no such file or directory"
>
> $ docker run --rm --privileged multiarch/qemu-user-static:register --reset
> $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m
> aarch64

Recently our multiarch project released a new feature to enable to run
a standard multi-architecture containers on x86_64, without
multiarch/* container that was needed before, not depending on host OS
environment.

That means below workflow works

```
$ uname -m
x86_64

$ docker run --rm -t arm64v8/ubuntu uname -m
standard_init_linux.go:211: exec user process caused "exec format error"

$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes

$ docker run --rm -t arm64v8/fedora:30 uname -m
aarch64
```

Is it fine to advertise my talk at Flock 2019 this Friday here? :)

Title: Let's add Fedora multiarch containers to your CI.
https://flock2019.sched.com/event/SJLx/lets-add-fedora-multiarch-containers-to-your-ci

* When: Friday August 9, 2019 10:30 - 10:55
* Where: the room Panorama (140m² / 40 people), The Danubius Hotel
HELIA in Budapest, Hungary, at Flock Budapest 2019

= Table of contents = (it might be changed a little bit later)
* Fedora and Upstream - Past and Present
* CPU Architecture Kinds
* Tools for multiarch - Today's topics
* QEMU and binfmt_misc - on News
* 5 steps - to add Fedora multiarch to upstream CI
* 1. qemu-$arch-static - An interpreter
* 2. binfmt_misc - A kernel feature for binary format
* 3. qemu-user-static RPM on Fedora
* 4. qemu-user-static RPM and container
* 5. multiarch/qemu-user-static image and CI
* Note A: ARM supported CI services
* Note B: A Dockerfile to multi-arch images
  docker buildx, docker/(podman) build --platform

Please come!

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

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
13 of 45 required tests failed, 8 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 40/147 (x86_64), 1/2 (arm)

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

ID: 429538  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/429538

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

ID: 429416  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/429416
ID: 429422  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/429422
ID: 429427  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/429427
ID: 429428  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429428
ID: 429430  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/429430
ID: 429431  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/429431
ID: 429432  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/429432
ID: 429433  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/429433
ID: 429434  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/429434
ID: 429435  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/429435
ID: 429436  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429436
ID: 429437  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/429437
ID: 429438  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/429438
ID: 429439  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/429439
ID: 429441  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/429441
ID: 429446  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429446
ID: 429447  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429447
ID: 429456  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/429456
ID: 429459  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429459
ID: 429462  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/429462
ID: 429463  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/429463
ID: 429464  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/429464
ID: 429465  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/429465
ID: 429474  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/429474
ID: 429477  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/429477
ID: 429479  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/429479
ID: 429480  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/429480
ID: 429520  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/429520
ID: 429541  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/429541
ID: 429542  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/429542
ID: 429543  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/429543
ID: 429544  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/429544
ID: 429547  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/429547
ID: 429548  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/429548
ID: 429549  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/429549
ID: 429551  Test: x86_64 

Re: Join the new Minimization Team

[Martin Kolman]

On Sun, 2019-08-04 at 16:18 +0100, Peter Robinson wrote:
> > > On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> > > > > I've already done some experiments with that. I used multi-stage 
> > > > > builds
> > > > > with podman, but it's the same in principle. And yes, the sizes are
> > > > > smaller. What was interesting though that some additional packages 
> > > > > (ones
> > > > > that wouldn't appear in the images using the Fedora base image) has 
> > > > > been
> > > > > dragged in as dependencies. Some of them are even related to 
> > > > > hardware. (See
> > > > > the report [1] and the github repo [2].)
> > > > 
> > > > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> > > > anymore.
> > > > 
> > > > A lot of the stuff in those images seems completely unnecessary:
> > > > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> > > > grubby, systemd-bootchart, systemd-udev.
> > > > 
> > > > > So that might be one area to focus on — to make sure that these "from
> > > > > scratch" installations don't drag unnecessary stuff.
> > > > 
> > > > Yep, that sounds like a good start. I suspect that F30 might be already
> > > > better in this regard.
> > > 
> > > Yes quite a bit has happened on the base image since F29, we have
> > > removed quite a few things and trimmed down the latest rawhide to
> > > 208MB. I am sure that can still be improved and I welcome any help on
> > > that :-).
> > 
> > I've regenerated it for f30 and f31: 
> > https://asamalik.fedorapeople.org/container-randomness/report.html
> > 
> > I see the fedora:f31 image is 195 MB, woot!
> 
> Is there a plan to add some form of CI to monitor this? It would make
> it easy to monitor ups/downs over time and pick up mistakes that bloat
> deps by accident.
I think such CI runs would be very useful even for other "classical" 
deliverables.

If the live image/netinst image/DVD image/installation initrd/etc. suddenly 
grows in size by say 20+ %, this is
something that should trigger warnings & should be investigated.


> ___
> 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: How do I remove GLIBCXX_ASSERTIONS?

[Sam Varshavchik]

Tom Hughes writes:


On 06/08/2019 09:37, Miroslav Lichvar wrote:


Ok, but does that mean the program has to abort? Could gcc do anything
dangerous here? If we were actually trying to catch undefined behavior
(e.g. with -fsanitize=undefined), I suspect Fedora wouldn't even boot
without a crash.


Well of course the program doesn't have to abort - we have chosen to
compile in a mode where it does.

We do that because by default this is invoking the nasal daemons clause
and the compiler is allowed to do absolutely anything it feels like.


Earlier in the thread I posted some conflicting references from the  
standard, related to the additional requirements of contiguous containers,  
and the specification of the "*" operator, that leaves some room open for  
interpretation, here.


If you go by the formal specification of container and iterator  
requirements, this is undefined behavior. But std::vector is also specified  
as having "additional" requirements of a "contiguous container", whose  
semantics are specified in terms of std::addressof behavior, and that rabbit  
hole goes in a slightly different direction.





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

Re: I wish to drop python2-certifi

[Petr Stodulka]

On 05. 08. 19 16:07, Miro Hrončok wrote:

On 29. 07. 19 16:01, Petr Stodulka wrote:

Hi Miro,
thanks for notification. I am thinking about that. From the point, that
Python2 is going to be death... Mabye I would take it, but I am fan of
removing Python2 stuff from Fedora. But Mercurial (hg-git, git-remote-hg,..)
is not compatible with Python3 yet (at least not a version released in
Fedora) but upstream is working on that. From that point, these components
will be updated as well later. So I am thinking whether it makes sense to
take these packages just until Python3-compatible Mercurial will be relased
(v5.0 provides beta support for Python3).
I see that v5.0 is built on OpenSUSE already, so I will look at it later
how does it look like in Fedora rawhide tonight/tomorrow's night.


Hi Petr,

any news on Python 3 mercurial?



Hi Miro,
so I played around and it looks that Python3 mercurial works from the point
of the elementary use (mercurial without extensions). But problem is, that
extensions are broken. Upstream declared that this is one of main problems
of transition to Python3 on which they are working on. It is question
whether there will be fixes for the most used extensions soon or not.
E.g. hgk extension we provide in in sub-package is broken instantly.
Not sure how people use mercurial (I am not fun of hg) so I will start
separate thread to discuss it with more details.


--
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Software Engineer
Red Hat Czech s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Nonresponsive maintainers jchaloup, lkundrak, jkaluza

[Peter Robinson]

> lkundrak
> https://bugzilla.redhat.com/show_bug.cgi?id=1737816
>https://bugzilla.redhat.com/show_bug.cgi?id=1716527

Lubomír is active, he's not always great at replying to emails but he
actively updates thing like NetworkManager and I believe he's based in
the Red Hat Brno office.

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: Orphaning/retiring 3 Java packages

[Marián Konček]

I could introduce Peter into Fedora java packaging.

On 24. 7. 2019 20:03, Peter Boy wrote:



Am 23.07.2019 um 16:08 schrieb Mikolaj Izdebski :

On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok  wrote:

On 23. 07. 19 13:27, Mikolaj Izdebski wrote:

Soon after Fedora 31 branching I intend to retire java-packaging-howto
package and orphan byaccj and javapackages-tools packages. The reason
is that I intend to maintain these packages as part of modules.

I will continue to maintain non-modular packages through lifecycles of
Fedora 29-31, but starting from Fedora 32 I will maintain modular
versions only.

Do you realize that while your decision to move essential bits of Java packaging
to modules might untie your hands a lot, it is causing everybody else involved
more and more trouble?

Perhaps I don't realize the trouble, could you elaborate? I expect
orphaned packages to be adopted by someone, likely a member of
Stewardship SIG. These two packages are low-maintenance and don't
require much work - they don't have many upstream changes and don't
get many bugs reported. So I don't see that much trouble in this case.


I acknowledge that it is your right to orphan essentially anything you want,
however the motivation here seems a bit... nonempathetic.

Would you mind to reconsider?

Definitely - this is the reason I wrote to the list. Do you have any
proposal what to do with these packages instead of orphaning them?


Sorry for jumping in. I think this might be an opportunity to participate in 
the Fedora Projekt. I’ve a lot of experience in java development and in 
creating application rpms, but none in the specialties of Fedora packaging. 
Would you accept me as co-maintainer and provide some guidance at the beginning?



Peter





--
Mikolaj Izdebski
___
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

—
Dr. Peter Boy
Universität Bremen
Mary-Sommerville-Str. 5
28359 Bremen
Germany

p...@zes.uni-bremen.de
www.zes.uni-bremen.de



Are you looking for a web content management system for scientific research 
organizations?
Have a look at http://www.scientificcms.org


Are you looking for a web content management system for public administrations?
Have a look at http://www.aplaws.org & https://fedorahosted.org/aplaws/
  
___

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


--

Marián Konček
___
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

Nonresponsive maintainers jchaloup, lkundrak, jkaluza

[Miro Hrončok]

Hello Jan, Lubomír, Jan.

Are you responsive? I try to reach your help in bugzilla for a while.


jchaloup
https://bugzilla.redhat.com/show_bug.cgi?id=1737815
  https://bugzilla.redhat.com/show_bug.cgi?id=1333990
  https://bugzilla.redhat.com/show_bug.cgi?id=1721645
  https://bugzilla.redhat.com/show_bug.cgi?id=1736473


lkundrak
https://bugzilla.redhat.com/show_bug.cgi?id=1737816
  https://bugzilla.redhat.com/show_bug.cgi?id=1716527


jkaluza
https://bugzilla.redhat.com/show_bug.cgi?id=1737818
  https://bugzilla.redhat.com/show_bug.cgi?id=1605882
  https://bugzilla.redhat.com/show_bug.cgi?id=1716525


Anybody else know show to contact the maintainers, if they don't reply?

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: NeuroFedora review swap: python-SALib

[Tomas Korbar]

Hi,
I could take this review. I hope you do not mind that i do not have package
in need of review.

On Tue, Aug 6, 2019 at 10:21 AM Ankur Sinha  wrote:

> Hello,
>
> Would anyone like to swap reviews please? python-SALib needs review for
> inclusion in NeuroFedora:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1737770
>
> It's a relatively simple package. Folks looking for sponsorship, please
> feel free to review it unofficially too.
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> 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

[Bug 1737781] New: Upgrade perl-Role-Tiny to 2.000008

[bugzilla]

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

Bug ID: 1737781
   Summary: Upgrade perl-Role-Tiny to 2.08
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Role-Tiny
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, emman...@seyman.fr, iarn...@gmail.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.07 version. Upstream released 2.08. When you
have free time, please upgrade it.

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Tom Hughes]

On 06/08/2019 09:37, Miroslav Lichvar wrote:

On Mon, Aug 05, 2019 at 09:36:47AM -0700, Andrew Lutomirski wrote:

On Mon, Aug 5, 2019 at 8:22 AM Andrew Lutomirski  wrote:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357

Depending on the resolution of that bug, I suggest that Fedora
consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
options.  IMO Fedora's default RPM build options should not cause
crashes on valid, if less-than-stylistically-great, code.  I don't
think that package maintainers should need to update package source to
use C++ in a more polite way.


And the bug has spoken.  v[v.size()] is undefined behavior.  Don't do it!


Ok, but does that mean the program has to abort? Could gcc do anything
dangerous here? If we were actually trying to catch undefined behavior
(e.g. with -fsanitize=undefined), I suspect Fedora wouldn't even boot
without a crash.


Well of course the program doesn't have to abort - we have chosen to
compile in a mode where it does.

We do that because by default this is invoking the nasal daemons clause
and the compiler is allowed to do absolutely anything it feels like.

Yes at the moment you might well find that in fact the compiler does
what people "expect" and, because it's only taking a reference, it never
tries to read the memory - that can change at any time however.

For an example see what happened when gcc got cleverer about assuming
that this won't be null in a method and started making optimisations
around that and things which had "worked" suddenly started crashing as
a result. Because they had been invoking undefined behaviour all along.

Obviously there is a trade off, which is why we don't compile everything
with sanitisers, because it would make them much slower - you should
absolutely build your code with them in development though and run all
your tests like that.

Presumably in this case the performance penalty was considered small
enough that it was worth building even production code with this mode
enabled.

Tom

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

Re: Intention to retire Release Notes RPM

[Martin Kolman]

On Mon, 2019-08-05 at 20:44 -0400, Neal Gompa wrote:
> On Mon, Aug 5, 2019 at 8:43 PM Martin Kolman  wrote:
> > On Sat, 2019-08-03 at 03:45 -0400, Neal Gompa wrote:
> > > On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd
> > >  wrote:
> > > > Hi All,
> > > > 
> > > > Barring objection, I plan to retire the release notes package from
> > > > Fedora on or after August 9, 2019.  The package has not been updated
> > > > since F28.  Despite the fact that we have literally shipped a package
> > > > containing the F28 release notes in F29 and F30, there have been no
> > > > comments.  This has been discussed with the docs team and is
> > > > supported.  I am not aware of any dependencies and I believe it was
> > > > removed from release criteria in F29.
> > > > 
> > > > I will run `fedpkg retire` and further request removal via
> > > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=fedora-obsolete-packages
> > > > 
> > > > Please reply on list if you have any questions or concerns.
> > > > 
> > > 
> > > Does Anaconda not support showing the release notes _anywhere_? That
> > > was the original impetus for shipping it that way...
> > There is currently no screen in either graphical or text interface of 
> > Anaconda that would show Fedora release notes.
> 
> Aside from it being mildly depressing that there's no way to discover
> the release notes for a Fedora release, I guess it's fine to retire.
> We don't have any other entry points in the distribution for viewing
> the release notes anymore...
At least for the online release notes, aren't they somewhere on the default 
landing page in Firefox after initial Fedora
installation ? I seem to remember something like that.
> 
> 
> -- 
> 真実はいつも一つ！/ 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
___
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-review seam to not work 8-(

[Vitaly Zaitsev via devel]

On 06.08.2019 2:06, Kevin Kofler wrote:
> Well, if there is no testsuite and if the headers are truly
> architecture-independent

Most of modern C++ header-only libraries provides Cmake scripts. Such
scripts will be installed to %{_libdir}/cmake/foo. That's why they
cannot be noarch.

-- 
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: How do I remove GLIBCXX_ASSERTIONS?

[Miroslav Lichvar]

On Mon, Aug 05, 2019 at 09:36:47AM -0700, Andrew Lutomirski wrote:
> On Mon, Aug 5, 2019 at 8:22 AM Andrew Lutomirski  wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357
> >
> > Depending on the resolution of that bug, I suggest that Fedora
> > consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
> > options.  IMO Fedora's default RPM build options should not cause
> > crashes on valid, if less-than-stylistically-great, code.  I don't
> > think that package maintainers should need to update package source to
> > use C++ in a more polite way.
> 
> And the bug has spoken.  v[v.size()] is undefined behavior.  Don't do it!

Ok, but does that mean the program has to abort? Could gcc do anything
dangerous here? If we were actually trying to catch undefined behavior
(e.g. with -fsanitize=undefined), I suspect Fedora wouldn't even boot
without a crash.

-- 
Miroslav Lichvar
___
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

NeuroFedora review swap: python-SALib

[Ankur Sinha]

Hello,

Would anyone like to swap reviews please? python-SALib needs review for
inclusion in NeuroFedora:

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

It's a relatively simple package. Folks looking for sponsorship, please
feel free to review it unofficially too.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

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

[updates]

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

argon2-20171227-3.el8
jhead-3.03-4.el8
pdns-4.1.11-3.el8
re2-20190801-1.el8

Details about builds:



 argon2-20171227-3.el8 (FEDORA-EPEL-2019-dee969692d)
 The password-hashing tools

Update Information:

Argon2 is a password-hashing function that summarizes the state of the artin the
design of memory-hard functions and can be used to hash passwordsfor credential
storage, key derivation, or other applications.  It has a simple design aimed at
the highest memory filling rate and effective use of multiple computing units,
while still providing defense against tradeoff attacks (by exploiting the cache
and memory organization of the recent processors).  Argon2 has three variants:
Argon2i, Argon2d, and Argon2id.  * Argon2d is faster and uses data-depending
memory access, which makes it   highly resistant against GPU cracking attacks
and suitable for applications   with no threats from side-channel timing attacks
(eg. cryptocurrencies). * Argon2i instead uses data-independent memory access,
which is preferred for   password hashing and password-based key derivation, but
it is slower as it   makes more passes over the memory to protect from tradeoff
attacks. * Argon2id is a hybrid of Argon2i and Argon2d, using a combination of
data-depending and data-independent memory accesses, which gives some of
Argon2i's resistance to side-channel cache timing attacks and much of
Argon2d's resistance to GPU cracking attacks.




 jhead-3.03-4.el8 (FEDORA-EPEL-2019-167ce24793)
 Tool for displaying EXIF data embedded in JPEG images

Update Information:

added patches to fix CVE-2019-1010301 and CVE-2019-1010302 from Debian




 pdns-4.1.11-3.el8 (FEDORA-EPEL-2019-3280c93462)
 A modern, advanced and high performance authoritative-only nameserver

Update Information:

The PowerDNS Nameserver is a modern, advanced and high performance
authoritative-only nameserver. It is written from scratch and conforms to all
relevant DNS standards documents. Furthermore, PowerDNS interfaces with almost
any database.




 re2-20190801-1.el8 (FEDORA-EPEL-2019-648f6bc55e)
 C++ fast alternative to backtracking RE engines

Update Information:

Upgrade to 2019-08-01

References:

  [ 1 ] Bug #1672014 - Update to the latest Re2
https://bugzilla.redhat.com/show_bug.cgi?id=1672014


___
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