[Bug 1678623] Review Request: strip-nondeterminism - File non-deterministic information stripper

[bugzilla]

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



--- Comment #8 from Sergio Monteiro Basto  ---
Dridi, you need update strip-nondeterminism.spec according to above mentioned,
to continue the review , until Peter approve this package .

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Issue with an update, need advice Re: [Fedora Update] [comment] papirus-icon-theme-20190302-1.fc30

[Robert-André Mauchin]

Hello,

I have an issue with the update of papirus-icon-theme: in the new version, 
symlinks 
have replaced what was previously folders and dnf errors out on this:

For example, on the current version:

$ ll /usr/share/icons/Papirus-Light/16x16

total 24K
drwxr-xr-x. 1 root root  73K nov.   6 16:36 actions/
lrwxrwxrwx. 1 root root   24 oct.  22 16:33 apps -> ../../Papirus/16x16/apps/
lrwxrwxrwx. 1 root root   30 oct.  22 16:33 categories -> 
../../Papirus/16x16/categories/
drwxr-xr-x. 1 root root 6,9K nov.   6 16:36 devices/
lrwxrwxrwx. 1 root root   27 oct.  22 16:33 emblems -> 
../../Papirus/16x16/emblems/
lrwxrwxrwx. 1 root root   27 oct.  22 16:33 emotes -> 
../../Papirus/16x16/emotes//
lrwxrwxrwx. 1 root root   29 oct.  22 16:33 mimetypes -> 
../../Papirus/16x16/mimetypes/
drwxr-xr-x. 1 root root  59K nov.   6 16:36 panel/
drwxr-xr-x. 1 root root 4,5K nov.   6 16:36 places/
lrwxrwxrwx. 1 root root   26 oct.  22 16:33 status -> 
../../Papirus/16x16/status/

On the new version:

$ ll /usr/share/icons/Papirus-Light/16x16

total 36K
lrwxrwxrwx. 1 root root  27 mars  11 16:16 actions -> 
../../Papirus/16x16/actions/
lrwxrwxrwx. 1 root root  24 mars  11 16:16 apps -> ../../Papirus/16x16/apps/
lrwxrwxrwx. 1 root root   4 mars  11 16:16 categories -> apps/
lrwxrwxrwx. 1 root root  27 mars  11 16:16 devices -> 
../../Papirus/16x16/devices/
lrwxrwxrwx. 1 root root  27 mars  11 16:16 emblems -> 
../../Papirus/16x16/emblems/
lrwxrwxrwx. 1 root root  26 mars  11 16:16 emotes -> ../../Papirus/16x16/emotes/
lrwxrwxrwx. 1 root root  29 mars  11 16:16 mimetypes -> 
../../Papirus/16x16/mimetypes/
drwxr-xr-x. 1 root root 60K mars  12 04:52 panel/
lrwxrwxrwx. 1 root root  26 mars  11 16:16 places -> ../../Papirus/16x16/places/
lrwxrwxrwx. 1 root root  26 mars  11 16:16 status -> ../../Papirus/16x16/status/


Why doesn't dnf simply remove the previous folders and replace them with 
symlinks?
How can I solve this?


On mardi 12 mars 2019 00:28:04 CET you wrote:
> The following comment has been added to the
> papirus-icon-theme-20190302-1.fc30 update:
> 
> bluepencil - 2019-03-11 23:28:03.749975 (karma: 0)
> Transaction check error:
>  file /usr/share/icons/Papirus-Light/16x16/devices from install of
> papirus-icon-theme-20190302-1.fc30.noarch conflicts with file from package
> papirus-icon-theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/16x16/places from install of
> papirus-icon-theme-20190302-1.fc30.noarch conflicts with file from package
> papirus-icon-theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/22x22/actions from install of
> papirus-icon-theme-20190302-1.fc30.noarch conflicts with file from package
> papirus-icon-theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/24x24/actions from install of
> papirus-icon-theme-20190302-1.fc30.noarch conflicts with file from package
> papirus-icon-theme-20181007-2.fc30.noarch
> 
> To reply to this comment, please visit the URL at the bottom of this mail
> 
> 
>  papirus-icon-theme-20190302-1.fc30
> 
>  Update ID: FEDORA-2019-0b6e471142
> Release: Fedora 30
>  Status: pending
>Type: enhancement
>Severity: unspecified
>   Karma: 0
> Request: testing
>Bugs: 1687463 - papirus-icon-theme-20190302 is available
>   Notes: Release 20190302 (#1687463)
>   Submitter: eclipseo
>   Submitted: 2019-03-11 15:12:44.615650
>Comments: bluepencil - 2019-03-11 23:28:03.749975 (karma 0)
>  Transaction check error:  file
>  /usr/share/icons/Papirus-Light/16x16/devices from
>  install of papirus-icon-theme-20190302-1.fc30.noarch
>  conflicts with file from package papirus-icon-
>  theme-20181007-2.fc30.noarch  file
>  /usr/share/icons/Papirus-Light/16x16/places from
>  install of papirus-icon-theme-20190302-1.fc30.noarch
>  conflicts with file from package papirus-icon-
>  theme-20181007-2.fc30.noarch  file
>  /usr/share/icons/Papirus-Light/22x22/actions from
>  install of papirus-icon-theme-20190302-1.fc30.noarch
>  conflicts with file from package papirus-icon-
>  theme-20181007-2.fc30.noarch  file
>  /usr/share/icons/Papirus-Light/24x24/actions from
>  install of papirus-icon-theme-20190302-1.fc30.noarch
>  conflicts with file from package papirus-icon-
>  theme-20181007-2.fc30.noarch
>  bluepencil - 2019-03-11 15:48:11.297750 (karma 0)
>  Error upgrading:   unpacking of archive failed on
>  file /usr/share/icons/Papirus-Light/16x16/actions:
>  cpio: File from package already exists as a directory
>  in system
>  bodhi - 2019-03-11 

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Huzaifa Sidhpurwala]

On 3/11/19 11:48 PM, Florian Weimer wrote:
> * Ben Cotton:
> 
>> '''-Wformat -Wformat-security -fstack-protector-strong
>> --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O'
> 
> --param=ssp-buffer-size=4 will not affect anything because
> -fstack-protector-strong uses a completely different heuristic.
> 
>> == Benefit to Fedora ==
>> We provide better security both for our packages and for
>> applications/programs which users are building.
> 
> We can check using annocheck if there are packages missing hardening and
> fix them.  What's the current level of coverage we have?
> 
The intention is to have a secure compiler defaults. I have not taken a
survey of what is the current coverage, but that is not really the goal
here. Also having secure defaults help with user applications and not
only fedora packages.

> Have the Red Hat Enterprise Linux 8 packaging changes been upstreamed?
> We were aiming for nearly-complete coverage there.
> 
Not sure about this, but again this is not the aim.
>> == Scope ==
>> * Proposal owners: Patch gcc to enable these options by default. Patch
>> should be very simple, since the compile/link code isnt actually
>> touched.
> 
> -D_FORTIFY_SOURCE=2 by default needs patching of glibc because of the
> pesky warning it prints without optimization.
What is the amount of work this requires? Can we aim this for F31? Also
these are warnings and not errors i assume?
> 
> What about PIE by defauld and non-lazy binding by default?  These two
> are probably the two hardest to get right with CFLAGS/LDFLAGS injection.
> (PIE is the reason for the -specs= hack.)
> 
I am aiming this for F32, The intention is to add small number of secure
defaults to GCC for each release. I am open to add PIE by default
though, if you feel its not going to break large number of packages.


> PIE-by-default compilers are very common already, although there are
> many StackOverflow questions from peopel who use them and follow older
> training material.
> 
> Thanks,
> Florian
> 


-- 
Huzaifa Sidhpurwala / Red Hat Product Security Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] Please review: Remove old spec files

[William Brown]

https://pagure.io/389-ds-base/issue/49668
https://pagure.io/389-ds-base/issue/49667

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

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-03-12 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



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

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

Re: Blocking criteria proposal for F30+: Printing

[Chris Murphy]

On Thu, Feb 28, 2019 at 2:56 PM Stephen Gallagher  wrote:

> * Printing must work on at least one printer available to Fedora QA.
> "Work" is defined as the output from the device matching a preview
> shown on the GNOME print preview display. (Note that non-ridiculous
> differences in color reproduction are not considered "non-working". In
> general, we'll apply the "last blocker at Go/No-Go" principle here
> when deciding whether a print glitch is truly blocking.)
>
> and this to Final for Fedora 30+:
> * Printing must work (as defined above) on at least one printer using
> each of the following drivers:
> - The built-in print-to-PDF driver
> - The generic IPP driver
> * For each blocking desktop, it must be possible to print:
> - A test page from the desktop environment's built-in "test page"
> feature, if such a feature exists.
> - A simple text document of at least 100 words (lorem ipsum) from
> the standard basic text editor accompanying that desktop.
>
> This does not mean that all printers need to function properly that
> use the IPP driver, just that at least one does (so we
> know that printing as a whole is unbroken). We won't specify any
> particular hardware makes or models that must work.

I think "generic IPP driver" needs to be more specifically stated.

There's IPP protocol versions 1.1, 2.0, 2.1 and 2.2. The "driverless"
specification is IPP Everywhere, which uses IPP protocol versions 2.0
or higher, along with additional requirements to support driverless
device discovery and printing of text and images. There isn't strictly
speaking a generic IPP driver, although PCL and PostScript are common.

What supports IPP Everywhere out of the box?

Any computer running CUPS 1.5 or later
Mobile devices running Android 4.4 and later

Proposal for Fedora 30: If anyone is able to, with reasonable effort,
successfully run the agreed test cases to any printer supporting IPP
2.0 or higher, using whatever driver is required, then we don't block.
Proposal for Fedora 31: If anyone is able to, with reasonable effort,
successfully run the agreed test cases to any IPP Everywhere printer,
then we don't block.

Something I need to dig into deeper is how to create a virtual IPP
Everywhere printer (a service); which would be useful for testing, in
particular automated testing such that the virtual printer itself says
"yes this is a valid print job". But also it might be possible to
bridge the virtual IPP Everywhere printer with a conventional
CUPS+gimp/foomatic driver based printer. If so, I'm thinking Fedora
IoT on a Raspberry Pi Zero W, using a static containerized approach,
that once working, should be a reliable indicator that any failures
coinciding with print pipeline changes in the client, are in fact
client bugs. But we'll see about that.

This might be useful:
IPP Everywhere mini-tutorial
https://github.com/apple/cups/wiki/IPP-(Everywhere)-Mini-Tutorial

Other references:
IPP Everywhere FAQ:
https://www.pwg.org/ipp/evefaq.html

IPP Everywhere self-certified printers list:
https://www.pwg.org/dynamo/eveprinters.php

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

Re: HEADS UP: python2-sphinx is going away on Monday (2019-03-11)

[Rex Dieter]

Miro Hrončok wrote:

> Due to https://fedoraproject.org/wiki/Changes/Sphinx2 we will be removing
> python2-sphinx and other related packages on Monday (2019-03-11).
...
> extra-cmake-modules  cicku dvratil heliocastro lkundrak rdieter

fixed extra-cmake-modules to use python3-sphinx, but ran into a bug where 
it fails, filed
https://bugzilla.redhat.com/show_bug.cgi?id=1687572

Disabling doc building on f31+ until that can be fixed.

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

[Bug 1687604] New: perl-Module-Starter-1.76 is available

[bugzilla]

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

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



Latest upstream release: 1.76
Current version/release in rawhide: 1.75-4.fc30
URL: http://search.cpan.org/dist/Module-Starter/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3114/

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Can't push to batched an Fedora 30 update?

[Tomasz Torcz]

On Mon, Mar 11, 2019 at 10:46:47AM -0400, Randy Barlow wrote:
> On Mon, 2019-03-11 at 10:35 -0400, Randy Barlow wrote:
> > On Mon, 2019-03-11 at 08:22 +, Richard W.M. Jones wrote:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-fd699ee2ea
> > > 
> > > "This update has reached 3 days in testing and can be pushed to
> > > stable
> > > now if the maintainer wishes"
> > > 
> > > Yes I'd like to, but there's no push to batched button!
> > 
> > I noticed this on one of my packages too today. I'm going to look
> > into
> > it now. My guess is that the front end was not updated with the
> > configuration change when Fedora 30 was added to Bodhi, but I am not
> > sure yet.
> 
> I have confirmed that the frontend has not been restarted since Fedora
> 30 was added, which would cause this problem. I've filed a freeze break
> request to get permission to rebuild the frontend containers with the
> config change:
> 
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/7X6B6BGFJ7SYZA243XOVPEJT7KVXRS24/

  Hmm, rebulding container on config change? Sounds fishy.
Have you tried putting production.ini into ConfigMap?

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1687197] perl-ExtUtils-Manifest-1.72 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-ExtUtils-Manifest-1.72-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-a0f9360b0e

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687224] perl-Sub-Quote-2.006003 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Sub-Quote-2.006003-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-daa3316272

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: HEADS UP: python2-sphinx is going away on Monday (2019-03-11)

[Richard Shaw]

On Fri, Mar 8, 2019 at 12:30 PM Miro Hrončok  wrote:

>
> hobbes1069 apiextractor python-requests-cache shiboken
>

I have updated apiextractor and python-requests-cache and verified they
will build.
shiboken was already FTBFS so I changed it over and performed builds.

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

Re: Fedora 31 System-Wide Change proposal: Gating Rawhide - Single package updates

[Miro Hrončok]

On 04. 03. 19 12:34, Pierre-Yves Chibon wrote:

On Sun, Mar 03, 2019 at 11:45:31AM +0100, Miro Hrončok wrote:

On 01. 03. 19 22:19, Ben Cotton wrote:

'''The CI system, the tests and the decision on which tests are used
to gate upon are out of scope for the present document.'''


This is both good (specifying explicitly what is this change about and what
it is not about) and bad...

Since the CI system is not part of this change, we cannot say this change is
not complete if the CI system is not complete. So later we say we have
rawhide gating and we'll all be \o/ \o/ \o/ yet nobody will care that the CI
is unfortunately:

  * not locally reproducible https://pagure.io/fedora-ci/general/issue/4
  * only working on on x86_64 https://pagure.io/fedora-ci/general/issue/16
  * unreadable https://pagure.io/fedora-ci/general/issue/2
  * unreliable (I file 1.75 issues per month on average)
  * understaffed (my personal observation)
  * tedious to start using (we focus on standards instead of UX)
  * untested (the (sometimes fatal) issues I face go unnoticed until I'm hit)

My concern is that the CI experience still feels a bit rough and I'd rather
see us focusing on making it better. This can of course be done in parallel
with this change, yet I feel that we are building this on water.

Note that I don't blame the CI people, they are very helpful and great to
work with, they just don't have time/resources/people.


I think you are raising very good points and that they should be looked into,
however, in the design of gating rawhide we tried to be test system agnostic,
so, as Adam already pointed out, you could gate on results any of our test
systems (we currently have three: the CI pipeline, taskotron, OpenQA) and
possibly other in the future.



Taskotron is planing to migrate to the CI pipeline.

https://pagure.io/fedora-ci/general/issue/36

So that leaves 2 things:

 * Fedora Ci with the above problems
 * OpenQA

I honestly don't except many packagers writing their own OpenQA tests.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Allowing Epoch to be reset between releases

[Jason L Tibbitts III]

> "VO" == Vít Ondruch  writes:

VO> In this case, if DNF said something like "you have installed
VO> foo-1:1.0, but there is available foo-0:2.0" it would give me
VO> hint. From the start it would be annoying, but once we would reach
VO> the point 4, I would, at least, know that I should do distrosync or
VO> something.

Under the proposal I put forward:

1. No releases except for rawhide would ever be affected by this,
   assuming that users upgrade using supported methods.

2. Rawhide users would need to do this exactly once per cycle, on an
   announced date.

So you would know that you should do distrosync because that would be
announced.

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

[EPEL-devel] Re: Epel7 Questions: Python34 - 36 transition

[Troy Dawson]

On Mon, Mar 11, 2019 at 9:42 AM Miro Hrončok  wrote:
>
> On 11. 03. 19 15:54, Troy Dawson wrote:
> > On Sat, Mar 9, 2019 at 8:16 PM Kevin Fenzi  wrote:
> >>
> >> On 3/9/19 7:15 PM, Troy Dawson wrote:
> >>> Hello,
> >>> There are a few questions I have, and since I'm not positive who all
> >>> of the correct people ask are, I'm sending to the epel-devel list.
> >>>
> >>> Before I start the questions, thank you to everyone who helped out in
> >>> getting the build failures working.  Thank you. thank you. thank you.
> >>>
> >>> We have all the python packages rebuilt.  All of the packages needed
> >>> for the rebuilds are tagged into override, and thus in the buildroot.
> >>> None of these rebuilt packages have been put into updates, and thus
> >>> are not in -testing.
> >>>
> >>> Where do we go from here?
> >>> A) Do I do one big update for all of the rebuilt packages?
> >>
> >> Yes.
> >>
> >>> B) Do I do individual updates for each package?
> >>> C) Some combination of above?
> >>
> >> Bad idea, as then some dependent packages could go out stable without
> >> all the packages they need.
> >>
> >>> D) Do a side tag, and take out all the overrides?
> >>
> >> Nope... side tag won't push them out, unless we just merge them into the
> >> main tag, but then they are bypassing testing.
> >>
> >>> I personally think C.  Do the main components (rpm macros, python34
> >>> and python36) in one update.  All the rest get their individual
> >>> update.
> >>
> >> All the other ones are going to need at least python36, so no, they
> >> should all be in one big update. Otherwise some of them could go stable
> >> and not have the python36 yet.
> >>
> >>> How long do we expect to be in this testing stage?
> >>
> >> I'd say at least 2 weeks?
> >>
> >>> If packagers want to update their python package for whatever reason,
> >>> what should they do?
> >>
> >> Build as usual, but ask someone to edit the update and remove the
> >> previous one and add in the new one.
> >>
> >> Thanks for building and coordinating everything!
> >>
> >> kevin
> >>
> >
> > Thanks for the feedback.  You too Miro.
> > After reading both of your reasons for doing A), I agree with you both.
> > Unless anyone objects, we'll plan to do option A
>
>
> Here is my build to include: python-distlib-0.2.7-3.el7
>
Added to my list of packages that will be in the update.
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Updating Rawhide vs GPG keys

[Fabio Valentini]

On Mon, Mar 11, 2019 at 7:30 PM Kevin Fenzi  wrote:

> On 3/11/19 4:31 AM, Vít Ondruch wrote:
> > Hi,
> >
> > Can somebody please enlighten me, how to update Rawhide after branching
> > and not using --nogpgcheck?
>
> Can you expand on the case here?
>
> What should happen is:
>
> * branching
> * f30 repos gets the f31 key
> * you update your f30-repos
> * you jump to rawhide and dnf just imports the key.
>
> How did you get on rawhide?
>

I'm having a similar problem, but with Silverblue / rawhide.

I installed the system when rawhide was still f30, but now I can't run
"rpm-ostree upgrade" anymore, due to this error:

Enabled rpm-md repositories: rawhide
Updating metadata for 'rawhide'... done
error: Failed to download gpg key for repo 'rawhide': Curl error (37):
Couldn't read a file:// file for
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 [Couldn't open file
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64]

So I'm *VERY* sure that I didn't mess with the system myself (since it's a
Silverblue installation), but still it's broken due to the missing GPG keys.

Fabio


> > It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
> > the package which is still "rawhide" package and has "f31" keys. But
> > this package was not probably signed, because this directory is empty:
> >
> >
> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
>
> Yeah, no longer shipped packages have their signed packages removed
> after a while to save space. You just want any newer one there.
>
> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/
> for example.
>
> > Installing anything from Rawhide fails, because of missing GPG keys.
> >
> > So is there a way to get the GPG keys via DNF? Would it be possible to
> > sign fedora-repos and fedora-release packages by older key to allow
> > smooth updates?
>
> The f30 repos should already include the f31 key.
>
>
> https://src.fedoraproject.org/rpms/fedora-repos/c/81ae6bcd584818d890f7939658884c5c9ec2e85c?branch=f30
>
> You can also get it from there:
>
> https://src.fedoraproject.org/rpms/fedora-repos/raw/f30/f/RPM-GPG-KEY-fedora-31-primary
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Epel7 Questions: Python34 - 36 transition

[Stephen John Smoogen]

On Mon, 11 Mar 2019 at 14:33, Kevin Fenzi  wrote:
>
> On 3/11/19 7:54 AM, Troy Dawson wrote:
>
> >
> > Thanks for the feedback.  You too Miro.
> > After reading both of your reasons for doing A), I agree with you both.
> > Unless anyone objects, we'll plan to do option A
> >
> > We only have one package left that fails it's rebuild, python-apsw.
> > I'm hoping someone can figure out the reason for the %checks failling. [1]
> > If we can get that fixed, I'll be all set to do the mass update later today.
> >
> > If we are only going to have these builds in -testing for a couple of
> > weeks, how about we shoot for April 2.
> > I'll be unavailable from March 20-April 2.  That would give us 3 weeks.
> > Hopefully by then we would have announcements made letting people know
> > the change is coming.
>
> Sounds good to me.
>
> As soon as the update exists and is pushed to testing we should mail
> epel-announce and possibly fedora-devel announce about it and mention
> that it will go stable in 3 weeks if nothing serious is found.
>
> And perhaps some blog posts or the like also?
>

Working on announcement and will post shortly.


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

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Nicolas Mailhot]

The change proposal is about integrating an entry point in rpmbuild to accept 
BR lists, at a moment of the build process where sources are already unpacked 
and processed.

It's an entry point. It does not restrict how you generate the BR data 
(upstream command, macro, cat somefile, echo foo, a mix of all of those, 
whatever works for the spec writer)

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

[EPEL-devel] Re: Epel7 Questions: Python34 - 36 transition

[Kevin Fenzi]

On 3/11/19 7:54 AM, Troy Dawson wrote:

> 
> Thanks for the feedback.  You too Miro.
> After reading both of your reasons for doing A), I agree with you both.
> Unless anyone objects, we'll plan to do option A
> 
> We only have one package left that fails it's rebuild, python-apsw.
> I'm hoping someone can figure out the reason for the %checks failling. [1]
> If we can get that fixed, I'll be all set to do the mass update later today.
> 
> If we are only going to have these builds in -testing for a couple of
> weeks, how about we shoot for April 2.
> I'll be unavailable from March 20-April 2.  That would give us 3 weeks.
> Hopefully by then we would have announcements made letting people know
> the change is coming.

Sounds good to me.

As soon as the update exists and is pushed to testing we should mail
epel-announce and possibly fedora-devel announce about it and mention
that it will go stable in 3 weeks if nothing serious is found.

And perhaps some blog posts or the like also?

kevin




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

Re: Updating Rawhide vs GPG keys

[Kevin Fenzi]

On 3/11/19 4:31 AM, Vít Ondruch wrote:
> Hi,
> 
> Can somebody please enlighten me, how to update Rawhide after branching
> and not using --nogpgcheck?

Can you expand on the case here?

What should happen is:

* branching
* f30 repos gets the f31 key
* you update your f30-repos
* you jump to rawhide and dnf just imports the key.

How did you get on rawhide?

> It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
> the package which is still "rawhide" package and has "f31" keys. But
> this package was not probably signed, because this directory is empty:
> 
> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/

Yeah, no longer shipped packages have their signed packages removed
after a while to save space. You just want any newer one there.
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/
for example.

> Installing anything from Rawhide fails, because of missing GPG keys.
> 
> So is there a way to get the GPG keys via DNF? Would it be possible to
> sign fedora-repos and fedora-release packages by older key to allow
> smooth updates?

The f30 repos should already include the f31 key.

https://src.fedoraproject.org/rpms/fedora-repos/c/81ae6bcd584818d890f7939658884c5c9ec2e85c?branch=f30

You can also get it from there:
https://src.fedoraproject.org/rpms/fedora-repos/raw/f30/f/RPM-GPG-KEY-fedora-31-primary

kevin



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

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Florian Weimer]

* Ben Cotton:

> '''-Wformat -Wformat-security -fstack-protector-strong
> --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O'

--param=ssp-buffer-size=4 will not affect anything because
-fstack-protector-strong uses a completely different heuristic.

> == Benefit to Fedora ==
> We provide better security both for our packages and for
> applications/programs which users are building.

We can check using annocheck if there are packages missing hardening and
fix them.  What's the current level of coverage we have?

Have the Red Hat Enterprise Linux 8 packaging changes been upstreamed?
We were aiming for nearly-complete coverage there.

> == Scope ==
> * Proposal owners: Patch gcc to enable these options by default. Patch
> should be very simple, since the compile/link code isnt actually
> touched.

-D_FORTIFY_SOURCE=2 by default needs patching of glibc because of the
pesky warning it prints without optimization.

What about PIE by defauld and non-lazy binding by default?  These two
are probably the two hardest to get right with CFLAGS/LDFLAGS injection.
(PIE is the reason for the -specs= hack.)

PIE-by-default compilers are very common already, although there are
many StackOverflow questions from peopel who use them and follow older
training material.

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

Re: Chromium C++ help needed

[Tom Callaway]

FWIW, I did. There is no fix there.

~tom

On Mon, Mar 11, 2019 at 1:20 PM Vascom  wrote:

> Look at chromium-vaapi build in rpmfusion.
>
> пн, 11 мар. 2019 г., 20:17 Tom Callaway :
>
>> Hi folks,
>>
>> I spent some time this weekend trying to get Chromium 72 building on
>> Fedora, but I kept running into a C++ issue that I was not able to resolve.
>> This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>>
>> Here's a sample of the error (it happens in a few places), from Fedora 30:
>>
>> In file included from
>> ../../base/trace_event/trace_event_system_stats_monitor.h:15,
>>  from ../../base/trace_event/trace_event.h:26,
>>  from ../../base/threading/scoped_blocking_call.cc:11:
>> ../../base/trace_event/trace_log.h: In constructor
>> 'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
>> ../../base/threading/scoped_blocking_call.cc:88:5:   in 'constexpr'
>> expansion of
>> 'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
>> char*)"base"))'
>> ../../base/trace_event/trace_log.h:215:25: error: '((&
>> base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
>> constant expression
>>   215 | if (builtin_category)
>>  | ^
>>
>> Now, chromium isn't the easiest code base to work with, but what seems to
>> be happening is that this code calls one of the TRACE_EVENT macros, like
>> this from base/threading/scoped_blocking_call.cc:
>>
>> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
>> static_cast(blocking_type));
>>
>> Those macros are defined in base/trace_event/common/trace_event_common.h:
>>
>> #define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val)
>>  \
>>   INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name,
>> \
>>TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
>>
>> INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
>>
>> / Implementation detail: internal macro to create static category and add
>> // event if the category is enabled.
>> #define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags,
>> ...)  \
>>   do {
>>  \
>> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);
>>   \
>> if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) {
>>  \
>>   trace_event_internal::AddTraceEvent(
>>  \
>>   phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name,
>>  \
>>   trace_event_internal::kGlobalScope,
>> trace_event_internal::kNoId, \
>>   flags, trace_event_internal::kNoId, ##__VA_ARGS__);
>>   \
>> }
>>   \
>>   } while (0)
>>
>> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
>> base/trace_event/trace_event.h:
>>
>> #define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
>>  \
>>   static_assert(
>>  \
>>
>> base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
>>   "Unknown tracing category is used. Please register your "
>>   \
>>   "category in base/trace_event/builtin_categories.h");
>>   \
>>   constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
>>  \
>>   k_category_group_enabled) =
>>   \
>>
>> base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group);  \
>>   const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
>>  \
>>   INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
>>   \
>>   category_group,
>> INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),  \
>>   INTERNAL_TRACE_EVENT_UID(category_group_enabled));
>>
>> Finally, inside here, it
>> calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
>> defined in base/trace_event/trace_log.h:
>>
>>   // Called by TRACE_EVENT* macros, don't call this directly.
>>   // The name parameter is a category group for example:
>>   // TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
>>   static const unsigned char* GetCategoryGroupEnabled(const char* name);
>>   static const char* GetCategoryGroupName(
>>   const unsigned char* category_group_enabled);
>>   static constexpr const unsigned char* GetBuiltinCategoryEnabled(
>>   const char* name) {
>> TraceCategory* builtin_category =
>> CategoryRegistry::GetBuiltinCategoryByName(name);
>> if (builtin_category)
>>   return builtin_category->state_ptr();
>> return nullptr;
>>   }
>>
>> Okay, so what seems like is happening here, is that the calls like this:
>>
>> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
>> static_cast(blocking_type));
>>
>> Are passing "base" (that first var) all the way into
>> GetCategoryGroupEnabled, which is finding it via GetBuiltinCategoryByName()
>> in base/trace_event/category_registry.h, checking against the list in
>> INTERNAL_TRACE_LIST_BUILTIN_CATEGORIES(X)
>> from base/trace_event/builtin_categories.h, finding it, then returning this
>> as builtin_category:
>>

Summary/Minutes from today's FESCo Meeting (2019-03-11)

[Petr Šabata]

=
#fedora-meeting-1: FESCO (2019-03-11)
=


Meeting started by contyk at 15:00:01 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-03-11/fesco.2019-03-11-15.00.log.html


Meeting summary
---
* init process  (contyk, 15:00:08)

* #2101 Fedora 30 incomplete changes  (contyk, 15:02:51)
  * LINK: https://pagure.io/fesco/issue/2101   (contyk, 15:02:56)
  * Firefox Wayland by default on GNOME -- FESCo would like to see this
Change land if it would not delay the Beta release. The standard
blocker/exception review will make the final call. If it does not
land in F30 Beta, this Change is Deferred to F31.  (contyk,
15:18:02)
  * LINK:

https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Freeze_exception_bug_principles
(zbyszek, 15:21:42)
  * Make BootLoaderSpec-style configuration files the default should be
ready now  (contyk, 15:26:01)
  * Haskell GHC 8.4 and Stackage LTS 12 -- if the maintainer wants this
change to land in F30, they need to push it as an update bundle,
otherwise defer to F31  (contyk, 15:34:05)
  * MongoDB removal -- the Change is implemented, but some dependencies
on removed packages remain. Those should be treated as bugs and
resolved in the usual fashion.  (contyk, 15:39:39)
  * LINK: https://pagure.io/pungi-fedora/pull-request/636 was the releng
change that blocked it going in for F29  (otaylor, 15:40:47)
  * LINK: https://src.fedoraproject.org/rpms/glibc32/commits/master
(mhroncok, 15:42:35)
  * glibc32 build adjustments -- not ready; there was no reply since we
moved this to f30. needinfo the change owner to ack it as f31
change. if there is no reply until we evaluate this for f31, we
cancel the change  (contyk, 15:46:44)
  * Build non-RELRO ELF binaries with .got.plt isolation -- also not
ready; there was no reply since we moved this to f30. needinfo the
change owner to ack it as f31 change. if there is no reply until we
evaluate this for f31, we cancel the change  (contyk, 15:48:39)
  * Reset locale if not available -- code ready but there's no build
yet; we'll follow the standard fe/blocker process; if it doesn't
land by beta, it will be deferred to f31  (contyk, 15:53:35)

* #2096 F31 System-Wide Change: BuildRequires generators  (contyk,
  15:55:18)
  * LINK: https://pagure.io/fesco/issue/2096   (contyk, 15:55:22)
  * We'll continue the discussion in the ticket for another week.
(contyk, 15:59:41)

* #2092 Fedora 31 schedule  (contyk, 16:01:13)
  * LINK: https://pagure.io/fesco/issue/2092   (contyk, 16:01:18)
  * AGREED: Fedora 31 schedule is APPROVED (+7, 0, -0)  (contyk,
16:19:36)

* #2027  RFC: Module lifecycles  (contyk, 16:19:49)
  * LINK: https://pagure.io/fesco/issue/2027   (contyk, 16:19:54)
  * LINK:

https://pagure.io/modularity/working-documents/c/dcd4d53df39b2500e19ad67b323fd90972046d94
(zbyszek, 16:22:19)
  * FESCo will review the new proposal within the following week
(contyk, 16:24:28)

* Next week's chair  (contyk, 16:24:49)
  * ACTION: jforbes will chair next meeting  (contyk, 16:25:52)

* Open Floor  (contyk, 16:25:57)

Meeting ended at 16:32:44 UTC.


Action Items

* jforbes will chair next meeting


Action Items, by person
---
* jforbes
  * jforbes will chair next meeting


People Present (lines said)
---
* contyk (117)
* mhroncok (89)
* sgallagh (61)
* zbyszek (52)
* nirik (49)
* bowlofeggs (36)
* zodbot (27)
* bcotton (23)
* bookwar (23)
* jforbes (22)
* otaylor (14)
* stransky_ (12)
* asamalik (7)
* kalev (6)
* ignatenkobrain (5)
* adamw (4)


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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Ben Cotton]

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

== Summary ==
By Default enable a few security hardening flags which are used with GCC.

== Owner ==
* Name: [[User:huzaifas|Huzaifa Sidhpurwala]]
* Email: huzai...@redhat.com
* Release notes owner: huzai...@redhat.com


== Detailed Description ==
Currently GCC does not enable any security hardening flags by default.
They have to be explicitly enabled by the developers one-by-one.
Ubuntu (https://wiki.ubuntu.com/ToolChain/CompilerFlags) however
enables them and therefore has a hardened compiler by default. Each of
these options can be explicitly disabled if required by the developer
via a GCC command line flag.  I am currently proposing the following
flags be enabled by default.

'''-Wformat -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O'

{| class="wikitable"
|-
! No !! Flag !! Use !! How to disable
|-
| 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make
sure that the arguments supplied have types appropriate to the format
string specified, and that the conversions specified in the  format
string make sense. || -Wno-format
|-
| 2 || -Wformat-security || If -Wformat is specified, also warn about
uses of format functions that represent possible security problems.
|| -Wno-format should disable this as well
|-
| 3 || -fstack-protector-strong || Like -fstack-protector but includes
additional functions to be protected --- those that have local array
definitions, or have references to local frame addresses.
|| -fno-stack-protector
|}


== Benefit to Fedora ==
We provide better security both for our packages and for
applications/programs which users are building.

== Scope ==
* Proposal owners: Patch gcc to enable these options by default. Patch
should be very simple, since the compile/link code isnt actually
touched.
* Other developers: Developers need to ensure that Fedora package is
built and if any build failures they are corrected
* Release engineering: [https://pagure.io/releng/issue/8204 #8204]
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: Not needed for this change

== Upgrade/compatibility impact ==
None

== How To Test ==
Run "gcc -Q -v " to check if these flags are enabled by default

== User Experience ==
Fedora is more secure because the entire distribution is compiled with
the correct security technologies enabled. Developers dont have to
worry about enabling the right flags when they compile their
application in Fedora because the compiler has them enabled by
default.

== Dependencies ==
All packages will be rebuild with new GCC options.

== Contingency Plan ==
* Contingency mechanism: Roll back the GCC options and use the default ones.
* Contingency deadline: Beta Feeze
* Blocks release? No




-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Review Fedora 30 deliverables

[Ben Cotton]

I'm late on this task, so I'm taking a broader approach. Please review
the list of release deliverables[1] and let me know if any need to be
added, removed, or have blocker status modified. Skimming the latest
complete compose, this seems to match, but it's better for the folks
responsible to verify it.

I will submit this to FESCo for final approval on Monday.

[1] https://fedoraproject.org/wiki/Releases/30/ReleaseBlocking

-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Ben Cotton]

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

== Summary ==
By Default enable a few security hardening flags which are used with GCC.

== Owner ==
* Name: [[User:huzaifas|Huzaifa Sidhpurwala]]
* Email: huzai...@redhat.com
* Release notes owner: huzai...@redhat.com


== Detailed Description ==
Currently GCC does not enable any security hardening flags by default.
They have to be explicitly enabled by the developers one-by-one.
Ubuntu (https://wiki.ubuntu.com/ToolChain/CompilerFlags) however
enables them and therefore has a hardened compiler by default. Each of
these options can be explicitly disabled if required by the developer
via a GCC command line flag.  I am currently proposing the following
flags be enabled by default.

'''-Wformat -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O'

{| class="wikitable"
|-
! No !! Flag !! Use !! How to disable
|-
| 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make
sure that the arguments supplied have types appropriate to the format
string specified, and that the conversions specified in the  format
string make sense. || -Wno-format
|-
| 2 || -Wformat-security || If -Wformat is specified, also warn about
uses of format functions that represent possible security problems.
|| -Wno-format should disable this as well
|-
| 3 || -fstack-protector-strong || Like -fstack-protector but includes
additional functions to be protected --- those that have local array
definitions, or have references to local frame addresses.
|| -fno-stack-protector
|}


== Benefit to Fedora ==
We provide better security both for our packages and for
applications/programs which users are building.

== Scope ==
* Proposal owners: Patch gcc to enable these options by default. Patch
should be very simple, since the compile/link code isnt actually
touched.
* Other developers: Developers need to ensure that Fedora package is
built and if any build failures they are corrected
* Release engineering: [https://pagure.io/releng/issue/8204 #8204]
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: Not needed for this change

== Upgrade/compatibility impact ==
None

== How To Test ==
Run "gcc -Q -v " to check if these flags are enabled by default

== User Experience ==
Fedora is more secure because the entire distribution is compiled with
the correct security technologies enabled. Developers dont have to
worry about enabling the right flags when they compile their
application in Fedora because the compiler has them enabled by
default.

== Dependencies ==
All packages will be rebuild with new GCC options.

== Contingency Plan ==
* Contingency mechanism: Roll back the GCC options and use the default ones.
* Contingency deadline: Beta Feeze
* Blocks release? No




-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Review Fedora 30 deliverables

[Ben Cotton]

I'm late on this task, so I'm taking a broader approach. Please review
the list of release deliverables[1] and let me know if any need to be
added, removed, or have blocker status modified. Skimming the latest
complete compose, this seems to match, but it's better for the folks
responsible to verify it.

I will submit this to FESCo for final approval on Monday.

[1] https://fedoraproject.org/wiki/Releases/30/ReleaseBlocking

-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Chromium C++ help needed

[Jakub Jelinek]

On Mon, Mar 11, 2019 at 01:16:07PM -0400, Tom Callaway wrote:
> I spent some time this weekend trying to get Chromium 72 building on
> Fedora, but I kept running into a C++ issue that I was not able to resolve.
> This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.

Can you please provide preprocessed source + g++ command line options,
from the snippets it is hard to see what's going on.
From the description it seems maybe like:
template 
struct S {
  static constexpr int a[2] = { 1, 2 };
};
static_assert (<0>::a[1] != nullptr);

which g++ accepts for -std=c++{11,14} but rejects for -std=c++{17,2a} when
S<0>::a is an inline variable.  I think we have a similar
http://gcc.gnu.org/PR89074 .  The middle-end punts here and doesn't optimize
the != NULL to true because it is address of a comdat variable and thus it
in the end could come up from any other TU.  Though perhaps in these cases
the standard gives us some guarantees.

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

Re: Chromium C++ help needed

[Vascom]

Look at chromium-vaapi build in rpmfusion.

пн, 11 мар. 2019 г., 20:17 Tom Callaway :

> Hi folks,
>
> I spent some time this weekend trying to get Chromium 72 building on
> Fedora, but I kept running into a C++ issue that I was not able to resolve.
> This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>
> Here's a sample of the error (it happens in a few places), from Fedora 30:
>
> In file included from
> ../../base/trace_event/trace_event_system_stats_monitor.h:15,
>  from ../../base/trace_event/trace_event.h:26,
>  from ../../base/threading/scoped_blocking_call.cc:11:
> ../../base/trace_event/trace_log.h: In constructor
> 'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
> ../../base/threading/scoped_blocking_call.cc:88:5:   in 'constexpr'
> expansion of
> 'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
> char*)"base"))'
> ../../base/trace_event/trace_log.h:215:25: error: '((&
> base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
> constant expression
>   215 | if (builtin_category)
>  | ^
>
> Now, chromium isn't the easiest code base to work with, but what seems to
> be happening is that this code calls one of the TRACE_EVENT macros, like
> this from base/threading/scoped_blocking_call.cc:
>
> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
> static_cast(blocking_type));
>
> Those macros are defined in base/trace_event/common/trace_event_common.h:
>
> #define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val) \
>   INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name, \
>TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
>
> INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
>
> / Implementation detail: internal macro to create static category and add
> // event if the category is enabled.
> #define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags, ...)
> \
>   do {
>  \
> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);
> \
> if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) {
>  \
>   trace_event_internal::AddTraceEvent(
>  \
>   phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name,
>  \
>   trace_event_internal::kGlobalScope, trace_event_internal::kNoId,
> \
>   flags, trace_event_internal::kNoId, ##__VA_ARGS__);
> \
> }
> \
>   } while (0)
>
> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
> base/trace_event/trace_event.h:
>
> #define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
>  \
>   static_assert(
>  \
>
> base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
>   "Unknown tracing category is used. Please register your "
> \
>   "category in base/trace_event/builtin_categories.h");
> \
>   constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
>  \
>   k_category_group_enabled) =
> \
>
> base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group);  \
>   const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
>  \
>   INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
> \
>   category_group, INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),
> \
>   INTERNAL_TRACE_EVENT_UID(category_group_enabled));
>
> Finally, inside here, it
> calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
> defined in base/trace_event/trace_log.h:
>
>   // Called by TRACE_EVENT* macros, don't call this directly.
>   // The name parameter is a category group for example:
>   // TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
>   static const unsigned char* GetCategoryGroupEnabled(const char* name);
>   static const char* GetCategoryGroupName(
>   const unsigned char* category_group_enabled);
>   static constexpr const unsigned char* GetBuiltinCategoryEnabled(
>   const char* name) {
> TraceCategory* builtin_category =
> CategoryRegistry::GetBuiltinCategoryByName(name);
> if (builtin_category)
>   return builtin_category->state_ptr();
> return nullptr;
>   }
>
> Okay, so what seems like is happening here, is that the calls like this:
>
> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
> static_cast(blocking_type));
>
> Are passing "base" (that first var) all the way into
> GetCategoryGroupEnabled, which is finding it via GetBuiltinCategoryByName()
> in base/trace_event/category_registry.h, checking against the list in
> INTERNAL_TRACE_LIST_BUILTIN_CATEGORIES(X)
> from base/trace_event/builtin_categories.h, finding it, then returning this
> as builtin_category:
>
> (& base::trace_event::CategoryRegistry::categories_[7])
>
> When if(builtin_category) is run (trying to check to see if we got a
> buillt-in category or a nullptr, I think), thats when GCC says:
>
> error: '((& 

Chromium C++ help needed

[Tom Callaway]

Hi folks,

I spent some time this weekend trying to get Chromium 72 building on
Fedora, but I kept running into a C++ issue that I was not able to resolve.
This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.

Here's a sample of the error (it happens in a few places), from Fedora 30:

In file included from
../../base/trace_event/trace_event_system_stats_monitor.h:15,
 from ../../base/trace_event/trace_event.h:26,
 from ../../base/threading/scoped_blocking_call.cc:11:
../../base/trace_event/trace_log.h: In constructor
'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
../../base/threading/scoped_blocking_call.cc:88:5:   in 'constexpr'
expansion of
'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
char*)"base"))'
../../base/trace_event/trace_log.h:215:25: error: '((&
base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
constant expression
  215 | if (builtin_category)
 | ^

Now, chromium isn't the easiest code base to work with, but what seems to
be happening is that this code calls one of the TRACE_EVENT macros, like
this from base/threading/scoped_blocking_call.cc:

TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
static_cast(blocking_type));

Those macros are defined in base/trace_event/common/trace_event_common.h:

#define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val) \
  INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name, \
   TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)

INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:

/ Implementation detail: internal macro to create static category and add
// event if the category is enabled.
#define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags, ...)  \
  do { \
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);\
if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) {   \
  trace_event_internal::AddTraceEvent( \
  phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name,   \
  trace_event_internal::kGlobalScope, trace_event_internal::kNoId, \
  flags, trace_event_internal::kNoId, ##__VA_ARGS__);  \
}  \
  } while (0)

INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
base/trace_event/trace_event.h:

#define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
   \
  static_assert(
   \

base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
  "Unknown tracing category is used. Please register your "
\
  "category in base/trace_event/builtin_categories.h");
\
  constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
   \
  k_category_group_enabled) =
\

base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group);  \
  const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
   \
  INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
\
  category_group, INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),
\
  INTERNAL_TRACE_EVENT_UID(category_group_enabled));

Finally, inside here, it
calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
defined in base/trace_event/trace_log.h:

  // Called by TRACE_EVENT* macros, don't call this directly.
  // The name parameter is a category group for example:
  // TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
  static const unsigned char* GetCategoryGroupEnabled(const char* name);
  static const char* GetCategoryGroupName(
  const unsigned char* category_group_enabled);
  static constexpr const unsigned char* GetBuiltinCategoryEnabled(
  const char* name) {
TraceCategory* builtin_category =
CategoryRegistry::GetBuiltinCategoryByName(name);
if (builtin_category)
  return builtin_category->state_ptr();
return nullptr;
  }

Okay, so what seems like is happening here, is that the calls like this:

TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
static_cast(blocking_type));

Are passing "base" (that first var) all the way into
GetCategoryGroupEnabled, which is finding it via GetBuiltinCategoryByName()
in base/trace_event/category_registry.h, checking against the list in
INTERNAL_TRACE_LIST_BUILTIN_CATEGORIES(X)
from base/trace_event/builtin_categories.h, finding it, then returning this
as builtin_category:

(& base::trace_event::CategoryRegistry::categories_[7])

When if(builtin_category) is run (trying to check to see if we got a
buillt-in category or a nullptr, I think), thats when GCC says:

error: '((& base::trace_event::CategoryRegistry::categories_[7]) != 0)' is
not a constant expression

*

None of the other distros that 

Re: Updating Rawhide vs GPG keys

[Jan Pokorný]

On 11/03/19 15:01 +0100, Jan Pokorný wrote:
> On 11/03/19 12:31 +0100, Vít Ondruch wrote:
>> Can somebody please enlighten me, how to update Rawhide after branching
>> and not using --nogpgcheck?
> 
> Good question; have observed this over several (if not all since
> to-be-f26 based Rawhide) jumps like that, and always have solved this
> inconvenience by hand and moved on.
> 
> GPG signatures related must-do consequence of branching for those
> using mock with the branched + Rawhide targets is also to update
> mock-core-configs, which is currently also not very straightforward
> and could perhaps be handled more gracefully:
> https://bugzilla.redhat.com/show_bug.cgi?id=1686869

Actually, fedora:rawhide container from Docker Hub (in CI scenario
here) is affected with this problem as well (cannot update with the
new-key-signed f30/f31 packages because of this, making the CI
procedure fail[*]).

Should not at least the "official container images" follow the
branching point automatically and promptly to prevent GPG signature
imposed disruptions ASAP?

[*] https://gitlab.com/poki/pacemaker/-/jobs/175445117

-- 
Jan (Poki)


pgp0147O15hL1.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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: HEADS UP: python2-sphinx is going away on Monday (2019-03-11)

[Miro Hrončok]

On 08. 03. 19 19:29, Miro Hrončok wrote:
Due to https://fedoraproject.org/wiki/Changes/Sphinx2 we will be removing 
python2-sphinx and other related packages on Monday (2019-03-11).


Done.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Epel7 Questions: Python34 - 36 transition

[Miro Hrončok]

On 11. 03. 19 15:54, Troy Dawson wrote:

On Sat, Mar 9, 2019 at 8:16 PM Kevin Fenzi  wrote:


On 3/9/19 7:15 PM, Troy Dawson wrote:

Hello,
There are a few questions I have, and since I'm not positive who all
of the correct people ask are, I'm sending to the epel-devel list.

Before I start the questions, thank you to everyone who helped out in
getting the build failures working.  Thank you. thank you. thank you.

We have all the python packages rebuilt.  All of the packages needed
for the rebuilds are tagged into override, and thus in the buildroot.
None of these rebuilt packages have been put into updates, and thus
are not in -testing.

Where do we go from here?
A) Do I do one big update for all of the rebuilt packages?


Yes.


B) Do I do individual updates for each package?
C) Some combination of above?


Bad idea, as then some dependent packages could go out stable without
all the packages they need.


D) Do a side tag, and take out all the overrides?


Nope... side tag won't push them out, unless we just merge them into the
main tag, but then they are bypassing testing.


I personally think C.  Do the main components (rpm macros, python34
and python36) in one update.  All the rest get their individual
update.


All the other ones are going to need at least python36, so no, they
should all be in one big update. Otherwise some of them could go stable
and not have the python36 yet.


How long do we expect to be in this testing stage?


I'd say at least 2 weeks?


If packagers want to update their python package for whatever reason,
what should they do?


Build as usual, but ask someone to edit the update and remove the
previous one and add in the new one.

Thanks for building and coordinating everything!

kevin



Thanks for the feedback.  You too Miro.
After reading both of your reasons for doing A), I agree with you both.
Unless anyone objects, we'll plan to do option A



Here is my build to include: python-distlib-0.2.7-3.el7

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

Re: Can't push to batched an Fedora 30 update?

[Randy Barlow]

This should be resolved now. Sorry for the issues!


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Guidance for a new contributor

[Sasa Savic]

> On March 11, 2019 at 3:28 PM Zbigniew Jędrzejewski-Szmek  
> wrote:
> If you are interested in python, then there's a big effort underway to
> port things over to python3 and remove python2 altogether from Fedora
> in the future
> (https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal,
> https://fedoraproject.org/wiki/Changes/Sphinx2,
> https://fedora.portingdb.xyz/). If you follow those links, you can
> find large amount of things to fix. You could for example open pull
> requests in src.fp.o for various packages that still need to be update.
> 
> Zbyszek

I'm interested, I was going though portingdb during the weekend. I guess I'll 
start right away :)
Zbyszek, thank you for the directions. 

Saša Savić
https://sasa-savic.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] please review: PR 50274 - reduce replication agmt default timeout

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50274
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)

[Randy Barlow]

On Fri, 2019-03-08 at 16:19 -0600, Jason L Tibbitts III wrote:
> * Bodhi shouldn't be involved here as this would be restricted to
>   rawhide.

Just a note that we do have plans to use Bodhi to manage Rawhide in the
future, and will hopefully have it doing this in 2019.

Bodhi is not currently Epoch-aware, but I wouldn't be opposed to
teaching it about Epochs if we wanted to make a change in this area.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Tomas Tomecek]

Is the expected workflow to be that I'd put these two lines to my spec file?

%generate_buildrequires
some-tool generate-rpm-buildreqs %{_builddir}

I'm interested if:
1. Generators will be separated from RPM codebase.
2. What the interface b/w a generator and rpm tool will be.
3. What are the expectations for responsibilities? Should I be
expected to invoke the generator or will language ecosystems update
their macro packages to provide wrappers on top
%generate_buildrequires?


Thanks,

Tomas

On Mon, Feb 18, 2019 at 9:21 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/BuildRequires_Generators
>
> = BuildRequires Generators =
>
> == Summary ==
> Add possibility to generate build-time dependencies within RPM spec
> file and teach RPM and mock how to handle this.
>
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian
> Festi]], [[User:msuchy|Miroslav Suchý]]
> * Email: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, 
> miros...@suchy.cz
>
> == Detailed Description ==
> For many languages (Rust, Golang, Node.Js, Ruby, Python),
> BuildRequires can be automatically generated. All it takes, run some
> special tool which will output dependencies in RPM format.
>
> Q: How will it work under the hood?
> A: When you build RPM, something like this will happen under the hood…
> # rpm would perform %prep (which is supposed to abort if some
> dependencies missing and print them)
> # mock would install those dependencies and resume build
>
> Q: Will src.rpm contain all generated dependencies?
> A: This is not known yet, we'll update page once it is known.
>
> Q: Does this mean that package builds won't be reproducible anymore?
> A: No, as long as you have same buildroot and tool which is generating
> BuildRequires is doing so in reproducible manner, it should not affect
> reproducibility.
>
> == Benefit to Fedora ==
>
> Packagers won't have to pre-generate BuildRequires in the spec file
> which means it will be always updated (and correct) :
>
> * Packagers can focus of making their packages better instead of
> spending all their packaging time copying BuildRequires from
> documentation and third party tools.
> * BuildRequires are dropped as soon as they're no longer necessary
> * Packages can be easily bumped without requiring a manual BuildRequires 
> refresh
> * BuildRequires and Requires generation can use similar utilities,
> making sure that the deps packages declare can also be used for
> second-level building. Packages no longer need to declare the deps of
> their second and n-th dependencies because someone forgot to declare
> them in the correct package.
>
> == Scope ==
> * Proposal owners: Implement support for a feature in RPM and mock (if
> implemented properly, Koji should just work). Make use of it in Rust
> ecosystem.
> * Other developers: Maintainers of language stacks are advised to use
> this feature.
> * Release engineering: [https://pagure.io/releng/issue/8129 #8129]
> * Policies and guidelines: Packaging Guidelines need to be updated
> with instructions how to use this feature.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Packagers and users who use repoquery might be affected (src.rpm might
> not contain generated dependencies).
>
> == How To Test ==
> TBD.
>
> == User Experience ==
> Users won't notice differences.
>
> == Dependencies ==
> Required feature needs to be implemented in RPM and mock.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) Proposal
> Owners might still ship feature disabled for Fedora buildsystem but
> have it available for end-users, and move full completion to the next
> release.
> * Contingency deadline: Beta Freeze
> * Blocks release? No.
> * Blocks product? No.
>
> == Documentation ==
> TBD.
>
> == Release Notes ==
> TBD.
>
> --
> Ben Cotton
> Fedora Program Manager
> 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://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Epel7 Questions: Python34 - 36 transition

[Stephen John Smoogen]

On Mon, 11 Mar 2019 at 10:54, Troy Dawson  wrote:
>
> On Sat, Mar 9, 2019 at 8:16 PM Kevin Fenzi  wrote:
> >
> > On 3/9/19 7:15 PM, Troy Dawson wrote:
> > > Hello,
> > > There are a few questions I have, and since I'm not positive who all
> > > of the correct people ask are, I'm sending to the epel-devel list.
> > >
> > > Before I start the questions, thank you to everyone who helped out in
> > > getting the build failures working.  Thank you. thank you. thank you.
> > >
> > > We have all the python packages rebuilt.  All of the packages needed
> > > for the rebuilds are tagged into override, and thus in the buildroot.
> > > None of these rebuilt packages have been put into updates, and thus
> > > are not in -testing.
> > >
> > > Where do we go from here?
> > > A) Do I do one big update for all of the rebuilt packages?
> >
> > Yes.
> >
> > > B) Do I do individual updates for each package?
> > > C) Some combination of above?
> >
> > Bad idea, as then some dependent packages could go out stable without
> > all the packages they need.
> >
> > > D) Do a side tag, and take out all the overrides?
> >
> > Nope... side tag won't push them out, unless we just merge them into the
> > main tag, but then they are bypassing testing.
> >
> > > I personally think C.  Do the main components (rpm macros, python34
> > > and python36) in one update.  All the rest get their individual
> > > update.
> >
> > All the other ones are going to need at least python36, so no, they
> > should all be in one big update. Otherwise some of them could go stable
> > and not have the python36 yet.
> >
> > > How long do we expect to be in this testing stage?
> >
> > I'd say at least 2 weeks?
> >
> > > If packagers want to update their python package for whatever reason,
> > > what should they do?
> >
> > Build as usual, but ask someone to edit the update and remove the
> > previous one and add in the new one.
> >
> > Thanks for building and coordinating everything!
> >
> > kevin
> >
>
> Thanks for the feedback.  You too Miro.
> After reading both of your reasons for doing A), I agree with you both.
> Unless anyone objects, we'll plan to do option A
>
> We only have one package left that fails it's rebuild, python-apsw.
> I'm hoping someone can figure out the reason for the %checks failling. [1]
> If we can get that fixed, I'll be all set to do the mass update later today.
>
> If we are only going to have these builds in -testing for a couple of
> weeks, how about we shoot for April 2.
> I'll be unavailable from March 20-April 2.  That would give us 3 weeks.
> Hopefully by then we would have announcements made letting people know
> the change is coming.
>

Sounds good. The possible 'fix' was to push to a newer version and
then edit it to not look at the older version of sqlite.

https://src.fedoraproject.org/fork/kanarip/rpms/
python-apsw/c/3fdeffe3e799e2305c821eb7d1bb710531ef7efe?branch=epel7-py36-by-apsw
38


> Troy
>
> [1] - https://koji.fedoraproject.org/koji/taskinfo?taskID=33397847
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org



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

[EPEL-devel] Re: Epel7 Questions: Python34 - 36 transition

[Troy Dawson]

On Sat, Mar 9, 2019 at 8:16 PM Kevin Fenzi  wrote:
>
> On 3/9/19 7:15 PM, Troy Dawson wrote:
> > Hello,
> > There are a few questions I have, and since I'm not positive who all
> > of the correct people ask are, I'm sending to the epel-devel list.
> >
> > Before I start the questions, thank you to everyone who helped out in
> > getting the build failures working.  Thank you. thank you. thank you.
> >
> > We have all the python packages rebuilt.  All of the packages needed
> > for the rebuilds are tagged into override, and thus in the buildroot.
> > None of these rebuilt packages have been put into updates, and thus
> > are not in -testing.
> >
> > Where do we go from here?
> > A) Do I do one big update for all of the rebuilt packages?
>
> Yes.
>
> > B) Do I do individual updates for each package?
> > C) Some combination of above?
>
> Bad idea, as then some dependent packages could go out stable without
> all the packages they need.
>
> > D) Do a side tag, and take out all the overrides?
>
> Nope... side tag won't push them out, unless we just merge them into the
> main tag, but then they are bypassing testing.
>
> > I personally think C.  Do the main components (rpm macros, python34
> > and python36) in one update.  All the rest get their individual
> > update.
>
> All the other ones are going to need at least python36, so no, they
> should all be in one big update. Otherwise some of them could go stable
> and not have the python36 yet.
>
> > How long do we expect to be in this testing stage?
>
> I'd say at least 2 weeks?
>
> > If packagers want to update their python package for whatever reason,
> > what should they do?
>
> Build as usual, but ask someone to edit the update and remove the
> previous one and add in the new one.
>
> Thanks for building and coordinating everything!
>
> kevin
>

Thanks for the feedback.  You too Miro.
After reading both of your reasons for doing A), I agree with you both.
Unless anyone objects, we'll plan to do option A

We only have one package left that fails it's rebuild, python-apsw.
I'm hoping someone can figure out the reason for the %checks failling. [1]
If we can get that fixed, I'll be all set to do the mass update later today.

If we are only going to have these builds in -testing for a couple of
weeks, how about we shoot for April 2.
I'll be unavailable from March 20-April 2.  That would give us 3 weeks.
Hopefully by then we would have announcements made letting people know
the change is coming.

Troy

[1] - https://koji.fedoraproject.org/koji/taskinfo?taskID=33397847
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Can't push to batched an Fedora 30 update?

[Randy Barlow]

On Mon, 2019-03-11 at 10:35 -0400, Randy Barlow wrote:
> On Mon, 2019-03-11 at 08:22 +, Richard W.M. Jones wrote:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-fd699ee2ea
> > 
> > "This update has reached 3 days in testing and can be pushed to
> > stable
> > now if the maintainer wishes"
> > 
> > Yes I'd like to, but there's no push to batched button!
> 
> I noticed this on one of my packages too today. I'm going to look
> into
> it now. My guess is that the front end was not updated with the
> configuration change when Fedora 30 was added to Bodhi, but I am not
> sure yet.

I have confirmed that the frontend has not been restarted since Fedora
30 was added, which would cause this problem. I've filed a freeze break
request to get permission to rebuild the frontend containers with the
config change:

https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/7X6B6BGFJ7SYZA243XOVPEJT7KVXRS24/


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide

[Dridi Boukelmoune]

> All that's broken is a 3rd party's assumption that their Epoch setting
> is greater than Fedora's. Assuming Ceph want to keep using Epoch in
> this way, upstream can simply bump their Epoch again to be greater than
> Fedora's new Epoch.

Or bump their Epoch to something much less likely to conflict in the
future, like 10 or 100.

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

[Bug 1687209] perl-strictures-2.000006 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-strictures-2.06-4.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9f5f97349f

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687197] perl-ExtUtils-Manifest-1.72 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-ExtUtils-Manifest-1.72-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-b77433ca26

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687224] perl-Sub-Quote-2.006003 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Sub-Quote-2.006003-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-a5bb214d07

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1686667] perl-Geo-Distance-0.24 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Geo-Distance-0.21-1.fc
   ||31



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Can't push to batched an Fedora 30 update?

[Randy Barlow]

On Mon, 2019-03-11 at 08:22 +, Richard W.M. Jones wrote:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-fd699ee2ea
> 
> "This update has reached 3 days in testing and can be pushed to
> stable
> now if the maintainer wishes"
> 
> Yes I'd like to, but there's no push to batched button!

I noticed this on one of my packages too today. I'm going to look into
it now. My guess is that the front end was not updated with the
configuration change when Fedora 30 was added to Bodhi, but I am not
sure yet.

> I guess this is something to do with "Failed to talk to Greenwave."?

This is a separate issue:

https://pagure.io/greenwave/issue/388


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Koji 1.17.0 and Python 3

[Neal Gompa]

On Mon, Mar 11, 2019 at 9:44 AM Peter Robinson  wrote:
>
> > I disabled autopushing precisely so that there's no accidental pushing
> > to stable updates. The worst thing that can happen is that we have to
> > unpush the update from testing. Seriously, that's really not the end
> > of the world.
> >
> > Nowhere did I say that releng needs to deploy this RIGHT NOW. Having
> > this in rawhide and F30 updates-testing makes it possible for the
> > dependency map for Python 2 to cleanup even more, allowing the Python
> > SIG to continue its work to clean out Python 2 subpackages in Fedora
> > 30/31.
>
> So if you've disabled/removed python2 support in Fedora 30 you've
> broken image building at least.
>

I double-checked this and you're sadly right. I've fixed this so
koji-builder is now using Python 2 again.

I thought I had validated all the dependencies for Koji we use in
infra to have been ported, but alas, imgfac hasn't been done yet.

Sorry all. I've learned my lesson. I'm not going to touch
infrastructure in Fedora directly again.



--
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Re: Guidance for a new contributor

[Zbigniew Jędrzejewski-Szmek]

On Sat, Mar 09, 2019 at 06:23:17PM +0100, Sasa Savic wrote:
> Hi all,
> 
> TLDR first,
> 
> I am:
> * Potential contributor, searching for guidance
> * Good with Python, C# (probably nobody cares) and JS, basics of C/C++
> * Experienced with everything above sys engineering (cli/gui, f/s webdev, ...)
> 
> Want to:
> * help first (port to py3, fix bug or two, help infra apps, ...)
> * learn (improve my c/cpp, work more in devops)
> 
> So, as you can see I really want to hop in and help in Fedora development.
> I dumped my side project which means I'll have probably ~10 weekly to work.
> Since I am not that creative and don't use a lot of tools, I don't have
> much to maintain for myself so I am willing to help towards goals for Fedora.
> 
> I'm most comfortable writing Python for any purpose. IMO that would be the
> best use of me (porting, tooling and/or web dev). On the other hand, I would
> really want to improve my C and I am willing to work hard on that. Also, I
> worked on developing tooling and could help infrastructure team.

If you are interested in python, then there's a big effort underway to
port things over to python3 and remove python2 altogether from Fedora
in the future
(https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal,
https://fedoraproject.org/wiki/Changes/Sphinx2,
https://fedora.portingdb.xyz/). If you follow those links, you can
find large amount of things to fix. You could for example open pull
requests in src.fp.o for various packages that still need to be update.

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

[Bug 1686667] perl-Geo-Distance-0.24 is available

[bugzilla]

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

Bug 1686788 Summary: Review Request: perl-GIS-Distance - Calculate geographic 
distances
https://bugzilla.redhat.com/show_bug.cgi?id=1686788

   What|Removed |Added

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



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

Re: Updating Rawhide vs GPG keys

[Jan Pokorný]

On 11/03/19 12:31 +0100, Vít Ondruch wrote:
> Can somebody please enlighten me, how to update Rawhide after branching
> and not using --nogpgcheck?

Good question; have observed this over several (if not all since
to-be-f26 based Rawhide) jumps like that, and always have solved this
inconvenience by hand and moved on.

GPG signatures related must-do consequence of branching for those
using mock with the branched + Rawhide targets is also to update
mock-core-configs, which is currently also not very straightforward
and could perhaps be handled more gracefully:
https://bugzilla.redhat.com/show_bug.cgi?id=1686869

-- 
Jan (Poki)


pgpgHuotr0lUS.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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide

[Daniel P . Berrangé]

On Mon, Mar 11, 2019 at 09:29:52AM -0400, Kaleb Keithley wrote:
> On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé 
> wrote:
> 
> > The ability to have multiple different builds of the same software which
> > users can choose between, sounds alot like the use case for modularity.
> > Abusing Epoch to try to address this kind of situation feels like a pretty
> > undesirable approach, as this problem with suddenly clashing Epochs will
> > illustrate.
> >
> 
> If only there had been modularity before f29 that might have been
> reasonable a reasonable claim, IMO.

Sure, in the past it wasn't possible, but I think it is a more viable
long term approach to the general scenerio.

> But it wasn't.  My issue is that there's no way to fix things when a
> mistake is made.
> 
> Perhaps I misunderstand the purpose of rawhide. I appreciate that "we" try
> to _not_ break things in rawhide, but when they do, there should be a way
> to fix them.

Well technically Fedora rawhide isn't actually broken by the epoch change.

All that's broken is a 3rd party's assumption that their Epoch setting
is greater than Fedora's. Assuming Ceph want to keep using Epoch in
this way, upstream can simply bump their Epoch again to be greater than
Fedora's new Epoch.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Schedule for Monday's FESCo Meeting (2019-03-11)

[Petr Šabata]

On Mon, Mar 11, 2019 at 09:56:35AM +0100, Petr Šabata wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
> irc.freenode.net.
> 
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
> 
> or run:
>   date -d '2019-03-11 15:00 UTC'
> 
> 
> Links to all issues to be discussed can be found at: 
> https://pagure.io/fesco/report/meeting_agenda
> 
> = Discussed and Voted in the Ticket =
> F31 System-Wide Change: Move Gold Into A SubpackageOf Binutils
> https://pagure.io/fesco/issue/2097
> ACCEPTED (+5, 0, -0)
> 
> F31 System-Wide Change: Automatic strict inter-package dependencies
> https://pagure.io/fesco/issue/2095
> ACCEPTED (+4, 0, -0)
> 
> F31 System-Wide Change: Python 3.8
> https://pagure.io/fesco/issue/2093
> ACCEPTED (+8, 0, -0)
> 
> require a re-review to unretire packages after 8 weeks instead of 2 weeks
> https://pagure.io/fesco/issue/2089
> ACCEPTED (+5, 0, -0)
> 
> = Followups =
> 
> #topic #2096 F31 System-Wide Change: BuildRequires generators
> .fesco 2096
> https://pagure.io/fesco/issue/2096
> 
> #topic #2092 Fedora 31 schedule
> .fesco 2092
> https://pagure.io/fesco/issue/2092

+

#topic #2027  RFC: Module lifecycles
.fesco 2027
https://pagure.io/fesco/issue/2027

> 
> = New business =
> 
> #topic #2101 Fedora 30 incomplete changes
> .fesco 2101
> https://pagure.io/fesco/issue/2101
> 
> = Open Floor = 
> 
> For more complete details, please visit each individual
> issue.  The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
> 
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, e-mail me directly, or bring it
> up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting. 



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



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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide

[Kaleb Keithley]

On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé 
wrote:

> The ability to have multiple different builds of the same software which
> users can choose between, sounds alot like the use case for modularity.
> Abusing Epoch to try to address this kind of situation feels like a pretty
> undesirable approach, as this problem with suddenly clashing Epochs will
> illustrate.
>

If only there had been modularity before f29 that might have been
reasonable a reasonable claim, IMO.

But it wasn't.  My issue is that there's no way to fix things when a
mistake is made.

Perhaps I misunderstand the purpose of rawhide. I appreciate that "we" try
to _not_ break things in rawhide, but when they do, there should be a way
to fix them.

--

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

Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide

[Neal Gompa]

On Mon, Mar 11, 2019 at 9:12 AM Kaleb Keithley  wrote:
>
>
>
> On Mon, Mar 11, 2019 at 8:22 AM Neal Gompa  wrote:
>>
>> Heck, the spec file
>> that is in Fedora is basically an openSUSE spec with Fedora
>> conditionals in it.
>
>
> The ceph.spec file in Fedora is  based on the upstream ceph.spec.in file; not 
> on anything in/from openSUSE.
>
> The upstream ceph.spec.in file is full of Fedora and SUSE conditionals.
>
> If openSUSE also used the upstream spec file then it shouldn't surprise 
> anyone that they are similar.
>

I'm keenly aware of where that spec file comes from, since I saw how
it was developed. It did start out as something for Fedora, but SUSE
folks started actively contributing in 2012 and merging their
packaging into upstream, changing it from a Fedora-style package to a
SUSE-style one.

Today, Ceph packaging in OBS is fetched through a source service and
used pretty much verbatim from upstream. I imagine you do something
similar to bring it downstream, too.

I'm not begrudging them of it, mind you. But it's a lie to say that it
isn't an openSUSE-style spec file. It's nice to know that we're mostly
compatible these days...



--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide

[Kaleb Keithley]

On Mon, Mar 11, 2019 at 8:22 AM Neal Gompa  wrote:

> Heck, the spec file
> that is in Fedora is basically an openSUSE spec with Fedora
> conditionals in it.
>

The ceph.spec file in Fedora is  based on the upstream ceph.spec.in file;
not on anything in/from openSUSE.

The upstream ceph.spec.in file is full of Fedora and SUSE conditionals.

If openSUSE also used the upstream spec file then it shouldn't surprise
anyone that they are similar.

--

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

Re: Updating Rawhide vs GPG keys

[Steven A. Falco]

On 3/11/19 7:31 AM, Vít Ondruch wrote:
> Hi,
> 
> Can somebody please enlighten me, how to update Rawhide after branching
> and not using --nogpgcheck?
> 
> It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
> the package which is still "rawhide" package and has "f31" keys. But
> this package was not probably signed, because this directory is empty:
> 
> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
> 
> Installing anything from Rawhide fails, because of missing GPG keys.
> 
> So is there a way to get the GPG keys via DNF? Would it be possible to
> sign fedora-repos and fedora-release packages by older key to allow
> smooth updates?
 
I was able to update by first manually updating the keys via:

cd /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages
rpm -Uvh \
fedora-gpg-keys-31-0.1.noarch.rpm \
fedora-release-31-0.1.noarch.rpm \
fedora-release-common-31-0.1.noarch.rpm \
fedora-repos-31-0.1.noarch.rpm \
fedora-repos-rawhide-31-0.1.noarch.rpm

Then I was able to do a normal "dnf update --refresh".

Note that your package directory location may be slightly different.  I don't 
know if the "rawhide-2d95c80a1fa0a67d" part is consistent or just where mine 
happened to be.  But if you search for one of the "keys" packages inside the 
dnf cache area you should be able to find it.

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

[EPEL-devel] Re: borgbackup: Rebuilt to change main python from 3.4 to 3.6

[Troy Dawson]

On Sat, Mar 9, 2019 at 8:19 PM Kevin Fenzi  wrote:
>
> On 3/9/19 7:16 PM, Troy Dawson wrote:
> > On Sat, Mar 9, 2019 at 9:47 AM Benjamin Pereto  
> > wrote:
> >>
> >> Hi,
> >>
> >> I saw that you rebuilt borgbackup (
> >> https://apps.fedoraproject.org/packages/borgbackup) for python3.6.
> >>
> >> thanks for that!
> >>
> >> Now I wanted to build a new package with the new upstream release and ran 
> >> in
> >> some issues to deploy.
> >> The package depends on python3-llfuse and python3-msgpack. Thanks to the
> >> buildroot the package is built successfully, but submit it to testing 
> >> would lead
> >> to install failures because of the missing new version of msgpack and 
> >> llfuse.
> >>
> >> How should I approach that? Is it needed that the maintainers of llfuse and
> >> msgpack push the new version first to stable?
> >>
> >> Best regards,
> >> Benjamin
> > Hi Benjamin,
> > This is a very good question.
> > I'm sending it to epel-devel, because I'm sure you aren't the only
> > person that is going to ask it, and I want to make sure I/we give a
> > consistent answer to everyone.
> > Also, I'm sorta just the proven packager that volunteered to do the
> > rebuild.  I'd rather the python-sig and/or developers give the final
> > answer.
> >
> > Epel Python Sig (or whoever was in charge of the python34 to python36
> > change), what should Benjamin do with his package?
>
> You (or whoever makes the big python36 update) should add in that new
> build to that big update so it goes out with everything else. ;)
>
> kevin
>

You have a good point Kevin.
I'll be tagging everything into an update today.  I'll just tag in the
newer borgbackup.  I've added this newer one to my list of packages
for the big update.

But in general, I think we need to have a statement on what to do
after I've done the big update.

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

Re: Don't lint in %check (Was: python-flake8 package not available in F30)

[Chris]

Noted,

I'll take this portion out. :)

Chris


On Mon., Mar. 11, 2019, 6:00 a.m. Petr Viktorin, 
wrote:

> On 3/9/19 7:33 PM, Chris wrote:
> > Thank you both for your fast reply!
> >
> >  >  Why do you need to BuildRequire a linting tool? What are you trying
> > to achieve?
> >
> > I just use python-flake8 as an OCD way of having my build fail if i fail
> > pep8 :)  It's just used in conjunction of my unit tests.
>
> Running a linter is fine upstream, but I'll argue that you'll be much
> better off disabling it for the distro build.
>
> Newer versions of flake8 can cause your tests to suddenly fail. We've
> seen that happen relatively often -- style standards themselves evolve,
> and the way they're codified in automatic tools evolves.
>
> Upstream, please do check code style or unused imports if that's your
> thing. But after you cut a release (on GitHub/PyPI), linting the code
> doesn't really bring any benefit. (Unlike running the test suite, of
> course.)
>
> Even if you're currently maintaining this both upstream and in Fedora,
> and have the energy to watch for & fix any failures, after some years
> you might want to pass the package on to someone else. Be nice to your
> successor. And be nice your potential Debian (et al.) maintainers by
> making your specfile show how to package for a distro :)
>
>
> (Note: AFAIK this is not official Fedora policy; please
> disagree/discuss/argue.)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Don't lint in %check (Was: python-flake8 package not available in F30)

[Dridi Boukelmoune]

On Mon, Mar 11, 2019 at 11:00 AM Petr Viktorin  wrote:
>
> On 3/9/19 7:33 PM, Chris wrote:
> > Thank you both for your fast reply!
> >
> >  >  Why do you need to BuildRequire a linting tool? What are you trying
> > to achieve?
> >
> > I just use python-flake8 as an OCD way of having my build fail if i fail
> > pep8 :)  It's just used in conjunction of my unit tests.
>
> Running a linter is fine upstream, but I'll argue that you'll be much
> better off disabling it for the distro build.
>
> Newer versions of flake8 can cause your tests to suddenly fail. We've
> seen that happen relatively often -- style standards themselves evolve,
> and the way they're codified in automatic tools evolves.

If upstream takes  seriously, and the package
maintainer does too, then following our First principle I would argue
it's fine to get an FTBFS as a result of an 
update iff the package maintainer is willing to patch their package
and upstream the patch.

> Upstream, please do check code style or unused imports if that's your
> thing. But after you cut a release (on GitHub/PyPI), linting the code
> doesn't really bring any benefit. (Unlike running the test suite, of
> course.)

But a release should be definitive, a "linter" bug is like any other
bug, it can be patched downstream and fixed in the next release.

> Even if you're currently maintaining this both upstream and in Fedora,
> and have the energy to watch for & fix any failures, after some years
> you might want to pass the package on to someone else. Be nice to your
> successor. And be nice your potential Debian (et al.) maintainers by
> making your specfile show how to package for a distro :)

As package maintainers we are supposed to stay in touch with upstream
projects, so letting them know about changes in 
should be part of that relationship.

> (Note: AFAIK this is not official Fedora policy; please
> disagree/discuss/argue.)

Same for me, just my personal opinion full of ifs :)

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

Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide

[Neal Gompa]

On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé  wrote:
>
> On Fri, Mar 08, 2019 at 03:07:09PM -0500, Kaleb Keithley wrote:
> > The epoch was inadvertently bumped (not by me) when ceph was rebased to
> > 14.x in f30/rawhide.
> >
> > I reset it to 1 in subsequent builds. Now adamwill is running builds with
> > it bumped to 2 again.
> >
> > I would prefer that it not be bumped. Ceph has their own builds (for Fedora
> > even I think) where they have epoch=2. I see this as a feature that lets
> > someone install Ceph's epoch=2 packages on a system and not risk
> > inadvertently updating with the Fedora Ceph packages.
>
> The ability to have multiple different builds of the same software which
> users can choose between, sounds alot like the use case for modularity.
> Abusing Epoch to try to address this kind of situation feels like a pretty
> undesirable approach, as this problem with suddenly clashing Epochs will
> illustrate.
>
> If ceph in Fedora were a module, is it possible for Ceph upstream to
> provide an alternate module stream of ceph too ?  If so, then users
> could use the normal modules features in DNF for deciding  which stream
> to have active on their systems.
>

If there was a material difference between upstream and downstream,
you might have a case for it. Today, there is not. Heck, the spec file
that is in Fedora is basically an openSUSE spec with Fedora
conditionals in it. It even has the (IMO dumb) license header thing
that openSUSE forces for all of its package spec files.

Not that it's necessarily a bad thing that the spec files are
identical, but I'd rather just say we should not care, since there's
no appreciable difference between the two.



-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)

[Mikolaj Izdebski]

On Mon, Mar 11, 2019 at 12:23 PM Neal Gompa  wrote:
> I don't remember how Plague handles this anymore (forgive me, but I
> haven't interacted with Plague since 2005!), but both Koji and OBS
> don't care if the Epoch goes up or down. Koji uses NVR as a key
> (without Epoch), and OBS freely allows EVRs to go up and down.

Some parts of Koji do rely on epoch not doing down. Notably,
koji-shadow uses epoch and it will stop working correctly when epoch
is removed or decreased. koji-shadow is not currently used by Fedora
project, but it may be used in future to bootstrap new architectures.
And it is still used by third parties to rebuild Fedora packages.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide

[Daniel P . Berrangé]

On Fri, Mar 08, 2019 at 03:07:09PM -0500, Kaleb Keithley wrote:
> The epoch was inadvertently bumped (not by me) when ceph was rebased to
> 14.x in f30/rawhide.
> 
> I reset it to 1 in subsequent builds. Now adamwill is running builds with
> it bumped to 2 again.
> 
> I would prefer that it not be bumped. Ceph has their own builds (for Fedora
> even I think) where they have epoch=2. I see this as a feature that lets
> someone install Ceph's epoch=2 packages on a system and not risk
> inadvertently updating with the Fedora Ceph packages.

The ability to have multiple different builds of the same software which
users can choose between, sounds alot like the use case for modularity.
Abusing Epoch to try to address this kind of situation feels like a pretty
undesirable approach, as this problem with suddenly clashing Epochs will
illustrate.

If ceph in Fedora were a module, is it possible for Ceph upstream to
provide an alternate module stream of ceph too ?  If so, then users
could use the normal modules features in DNF for deciding  which stream
to have active on their systems.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Updating Rawhide vs GPG keys

[Vít Ondruch]

Hi,

Can somebody please enlighten me, how to update Rawhide after branching
and not using --nogpgcheck?

It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
the package which is still "rawhide" package and has "f31" keys. But
this package was not probably signed, because this directory is empty:

https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/

Installing anything from Rawhide fails, because of missing GPG keys.

So is there a way to get the GPG keys via DNF? Would it be possible to
sign fedora-repos and fedora-release packages by older key to allow
smooth updates?


Vít

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

Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)

[Neal Gompa]

On Mon, Mar 11, 2019 at 6:48 AM Stephen John Smoogen  wrote:
>
> On Mon, 11 Mar 2019 at 05:29, Vít Ondruch  wrote:
> >
> >
> > Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a):
> > > On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch  wrote:
> > >>
> > >> Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a):
> > >>> Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a):
> > > "MH" == Miro Hrončok  writes:
> >  MH> On 08. 03. 19 21:16, Neal Gompa wrote:
> > >> I really wish we'd allow Epochs to be reset on distribution upgrades.
> > >> With dnf distro-sync (which is used by system-upgrade) Epochs don't
> > >> really matter and upgrades work as intended anyway...
> >  MH> Let's do a Fedora change? Coordinate with FPC?
> > 
> >  We (FPC) have talked about this before but I don't think it's really up
> >  to FPC.  The change process isn't really the right way to do it, 
> >  either,
> >  since this is really a policy revision.  I just think FESCo needs to
> >  decide whether or not it would like to relax the policy, and if so, 
> >  how.
> > 
> >  Here are the relevant points as I see them (unless I'm forgetting
> >  something):
> > 
> >  * dnf system-upgrade generally handles versions going backward without
> >    issue.  The specific case of epoch being reset is not an issue.
> > 
> >  * dnf upgrade would not handle this, causing problems for those running
> >    rawhide or using unsupported methods of upgrading between releases.
> > 
> >    * Those running rawhide would have to run distro-sync in order to
> >  upgrade (which would of course reset any locally built updated
> >  packages and such).  They would have to do this every time any
> >  installed package drops epoch.
> > 
> >    * Those using an unsupported method of upgrading would need to
> >  incorporate distro-sync.
> > 
> >    * Dropping epoch outside of rawhide would generally be bad.
> > 
> >  * Koji and the compose process do handle things "going backwards", as
> >    this has happened multiple times in the past without things dying.
> >    What's important there is which version was most recently tagged.
> > 
> >  * Bodhi shouldn't be involved here as this would be restricted to
> >    rawhide.
> > 
> >  Personally I'm in support of relaxing the restriction in some form, but
> >  I prefer a single "drop Epoch: day" where epochs in rawhide are
> >  _automatically_ removed and the packages rebuilt.  This gives a single
> >  point in time where rawhide users need to do a distro-sync in order to
> >  properly track updates.  Allowing epochs to be dropped without
> >  coordination seems to me to be a burden on rawhide users, but I don't
> >  think a single flag day would be problematic.
> > 
> >  I would expect the first flag day to be busy.  I see 756 Epoch: tags
> >  currently, though 161 are set to 0 for whatever reason.  Afterwards I
> >  would expect no more than a small number of packages per cycle to
> >  acquire Epoch: tags.
> > 
> >   - J<
> > >>> If DNF were helpful and was able to report packages, which has higher
> > >>> NVR then E(NVR),
> > >>
> > >> I meant (E)NVR actually.
> > >>
> > >>
> > >> V.
> > >>
> > >>
> > >>> then I can imagine that reset of epoch could work.
> > >>> Otherwise I am against resetting epochs.
> > >>>
> > > I'm confused, why would that matter? And DNF always reports NEVRA...
> > >
> > >
> >
> > The epoch are used in cases like:
> >
> > 1. There is  foo version 1.0
> >
> > 2. foo is updated to version 2.0, because it seems it is safe.
> >
> > 3. It is discovered, that it breaks stuff, so the decision is go back to
> > 1.0 and add epoch.
> >
> > 4. Eventually, we really want to have 2.0 in the release or even
> > something newer. Now, the epoch could be removed, but it is not
> > possible, because it has the highest priority.
> >
> >
> > In this case, if DNF said something like "you have installed foo-1:1.0,
> > but there is available foo-0:2.0" it would give me hint. From the start
> > it would be annoying, but once we would reach the point 4, I would, at
> > least, know that I should do distrosync or something.
> >
>
> Whatever changes to EPOCH rules will need additional logic added to
> all the various buildsystem logic where a human can't sit around and
> choose 'oh yeah I want to go to that older epoch' because the build is
> automated somewhere. This has been the major reason why various 'EPOCH
> should go back' or 'I want an EPOCH to my EPOCH' conversations in the
> past have floundered (I think we last looked at this in 2009 and I
> know we did in 1999.. so maybe this is a 10 year cycle?). There is a
> LOT of stuff written on the assumption that EPOCH's go forward and
> never backwards. Changing the rules here have effects in many many
> other build systems and install tools which sites are 

Re: RHEL8 and Mageia7 available in Copr

[Neal Gompa]

On Mon, Mar 11, 2019 at 7:05 AM Miroslav Suchý  wrote:
>
> Hi,
> I just added those chroots to Copr:
>   rhelbeta-8-x86_64
>   mageia-7-i586
>   mageia-7-x86_64
>
> Please be aware that there is no available EPEL for rhelbeta-8-x86_64 yet. 
> This chroot is intended for some initial
> bootstraping and testing prior RHEL 8 release and it will be removed from 
> Copr once RHEL 8 - or to be precise CentOS 8 -
> will be released.
>
> Before you ask - the F30 will be added in upcoming hours.
>

Thanks Mirek!

Also, thanks to clime, opensuse-leap-15.1-x86_64 has been enabled as well.



-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RHEL8 and Mageia7 available in Copr

[Miroslav Suchý]

Hi,
I just added those chroots to Copr:
  rhelbeta-8-x86_64
  mageia-7-i586
  mageia-7-x86_64

Please be aware that there is no available EPEL for rhelbeta-8-x86_64 yet. This 
chroot is intended for some initial
bootstraping and testing prior RHEL 8 release and it will be removed from Copr 
once RHEL 8 - or to be precise CentOS 8 -
will be released.

Before you ask - the F30 will be added in upcoming hours.

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

Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)

[Stephen John Smoogen]

On Mon, 11 Mar 2019 at 05:29, Vít Ondruch  wrote:
>
>
> Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a):
> > On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch  wrote:
> >>
> >> Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a):
> >>> Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a):
> > "MH" == Miro Hrončok  writes:
>  MH> On 08. 03. 19 21:16, Neal Gompa wrote:
> >> I really wish we'd allow Epochs to be reset on distribution upgrades.
> >> With dnf distro-sync (which is used by system-upgrade) Epochs don't
> >> really matter and upgrades work as intended anyway...
>  MH> Let's do a Fedora change? Coordinate with FPC?
> 
>  We (FPC) have talked about this before but I don't think it's really up
>  to FPC.  The change process isn't really the right way to do it, either,
>  since this is really a policy revision.  I just think FESCo needs to
>  decide whether or not it would like to relax the policy, and if so, how.
> 
>  Here are the relevant points as I see them (unless I'm forgetting
>  something):
> 
>  * dnf system-upgrade generally handles versions going backward without
>    issue.  The specific case of epoch being reset is not an issue.
> 
>  * dnf upgrade would not handle this, causing problems for those running
>    rawhide or using unsupported methods of upgrading between releases.
> 
>    * Those running rawhide would have to run distro-sync in order to
>  upgrade (which would of course reset any locally built updated
>  packages and such).  They would have to do this every time any
>  installed package drops epoch.
> 
>    * Those using an unsupported method of upgrading would need to
>  incorporate distro-sync.
> 
>    * Dropping epoch outside of rawhide would generally be bad.
> 
>  * Koji and the compose process do handle things "going backwards", as
>    this has happened multiple times in the past without things dying.
>    What's important there is which version was most recently tagged.
> 
>  * Bodhi shouldn't be involved here as this would be restricted to
>    rawhide.
> 
>  Personally I'm in support of relaxing the restriction in some form, but
>  I prefer a single "drop Epoch: day" where epochs in rawhide are
>  _automatically_ removed and the packages rebuilt.  This gives a single
>  point in time where rawhide users need to do a distro-sync in order to
>  properly track updates.  Allowing epochs to be dropped without
>  coordination seems to me to be a burden on rawhide users, but I don't
>  think a single flag day would be problematic.
> 
>  I would expect the first flag day to be busy.  I see 756 Epoch: tags
>  currently, though 161 are set to 0 for whatever reason.  Afterwards I
>  would expect no more than a small number of packages per cycle to
>  acquire Epoch: tags.
> 
>   - J<
> >>> If DNF were helpful and was able to report packages, which has higher
> >>> NVR then E(NVR),
> >>
> >> I meant (E)NVR actually.
> >>
> >>
> >> V.
> >>
> >>
> >>> then I can imagine that reset of epoch could work.
> >>> Otherwise I am against resetting epochs.
> >>>
> > I'm confused, why would that matter? And DNF always reports NEVRA...
> >
> >
>
> The epoch are used in cases like:
>
> 1. There is  foo version 1.0
>
> 2. foo is updated to version 2.0, because it seems it is safe.
>
> 3. It is discovered, that it breaks stuff, so the decision is go back to
> 1.0 and add epoch.
>
> 4. Eventually, we really want to have 2.0 in the release or even
> something newer. Now, the epoch could be removed, but it is not
> possible, because it has the highest priority.
>
>
> In this case, if DNF said something like "you have installed foo-1:1.0,
> but there is available foo-0:2.0" it would give me hint. From the start
> it would be annoying, but once we would reach the point 4, I would, at
> least, know that I should do distrosync or something.
>

Whatever changes to EPOCH rules will need additional logic added to
all the various buildsystem logic where a human can't sit around and
choose 'oh yeah I want to go to that older epoch' because the build is
automated somewhere. This has been the major reason why various 'EPOCH
should go back' or 'I want an EPOCH to my EPOCH' conversations in the
past have floundered (I think we last looked at this in 2009 and I
know we did in 1999.. so maybe this is a 10 year cycle?). There is a
LOT of stuff written on the assumption that EPOCH's go forward and
never backwards. Changing the rules here have effects in many many
other build systems and install tools which sites are using and that
usually ends up being too big of a problem to solve. [Yes we can fix
our koji/bodhi/greenwave/waiverdb/pungi/mock/copr, and their koji and
maybe that other other koji... but how do we fix the plague server
building stuff at large industrial complex-1 or the clone of the OSBS
at 

Re: Downgrading glibc from Rawhide removed /bin/sh (!)

[Florian Weimer]

* Panu Matilainen:

> It's glibc's own %post own scripts that are somehow breaking it. I've
> a minimal reproducer here with glibc 2.29 in /srv/root chroot. The
> bash version is just to show whether bash is alive or not:

Yes, you are right, I had actually looked at this failure a few weeks
ago and reached similar conclusions (my memory is failing).

> glibc's %post is /usr/sbin/glibc_post_upgrade., so that's what's
> doing something bad here. When straced through forks and all, guess
> what? It's running ldconfig:

Right, we have to do that unfortunately.

So the problem is not the symbolic link handling, but the fact that the
scriptlets run while old files still stick around, before RPM deletes
them closer to the end of the transaction.  And *this* happens because
we use symbolic links to the actual implementation.  If we didn't do
that, RPM would have no choice and would have to replace the files on
disk, so that the old version is gone.

We actually have compensating code in glibc_post_upgrade for these
lingering files, deleting files early that would break scriptlets which
run before they are deleted by RPM.

The question is whether we want to extend this code to cover more cases.
This is quite hard to do however, especially for downgrades, because we
do not know which files to delete in the %post scriptlet of the old
version (which cannot foretell the changes the newer glibc version that
is being removed brought in).  Presumably, we could look at the file
list in the RPM database and delete anything that's not part of the
current package version (the one whose %post is running).

I had already raised the issue with the symbolic links upstream (as I
said, my memory is failing), and feedback was not exactly positive:

  

In fact, Siddhesh suggested using *more* symbolic links:

  

What's RPM's justification for deleting files so late in the
transaction?  Can this be changed at the RPM level?  I'm sure we aren't
the only ones affected by this.

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

Don't lint in %check (Was: python-flake8 package not available in F30)

[Petr Viktorin]

On 3/9/19 7:33 PM, Chris wrote:

Thank you both for your fast reply!

 >  Why do you need to BuildRequire a linting tool? What are you trying 
to achieve?


I just use python-flake8 as an OCD way of having my build fail if i fail 
pep8 :)  It's just used in conjunction of my unit tests.


Running a linter is fine upstream, but I'll argue that you'll be much 
better off disabling it for the distro build.


Newer versions of flake8 can cause your tests to suddenly fail. We've 
seen that happen relatively often -- style standards themselves evolve, 
and the way they're codified in automatic tools evolves.


Upstream, please do check code style or unused imports if that's your 
thing. But after you cut a release (on GitHub/PyPI), linting the code 
doesn't really bring any benefit. (Unlike running the test suite, of 
course.)


Even if you're currently maintaining this both upstream and in Fedora, 
and have the energy to watch for & fix any failures, after some years 
you might want to pass the package on to someone else. Be nice to your 
successor. And be nice your potential Debian (et al.) maintainers by 
making your specfile show how to package for a distro :)



(Note: AFAIK this is not official Fedora policy; please 
disagree/discuss/argue.)

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

Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)

[Vít Ondruch]

Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a):
> On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch  wrote:
>>
>> Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a):
>>> Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a):
> "MH" == Miro Hrončok  writes:
 MH> On 08. 03. 19 21:16, Neal Gompa wrote:
>> I really wish we'd allow Epochs to be reset on distribution upgrades.
>> With dnf distro-sync (which is used by system-upgrade) Epochs don't
>> really matter and upgrades work as intended anyway...
 MH> Let's do a Fedora change? Coordinate with FPC?

 We (FPC) have talked about this before but I don't think it's really up
 to FPC.  The change process isn't really the right way to do it, either,
 since this is really a policy revision.  I just think FESCo needs to
 decide whether or not it would like to relax the policy, and if so, how.

 Here are the relevant points as I see them (unless I'm forgetting
 something):

 * dnf system-upgrade generally handles versions going backward without
   issue.  The specific case of epoch being reset is not an issue.

 * dnf upgrade would not handle this, causing problems for those running
   rawhide or using unsupported methods of upgrading between releases.

   * Those running rawhide would have to run distro-sync in order to
 upgrade (which would of course reset any locally built updated
 packages and such).  They would have to do this every time any
 installed package drops epoch.

   * Those using an unsupported method of upgrading would need to
 incorporate distro-sync.

   * Dropping epoch outside of rawhide would generally be bad.

 * Koji and the compose process do handle things "going backwards", as
   this has happened multiple times in the past without things dying.
   What's important there is which version was most recently tagged.

 * Bodhi shouldn't be involved here as this would be restricted to
   rawhide.

 Personally I'm in support of relaxing the restriction in some form, but
 I prefer a single "drop Epoch: day" where epochs in rawhide are
 _automatically_ removed and the packages rebuilt.  This gives a single
 point in time where rawhide users need to do a distro-sync in order to
 properly track updates.  Allowing epochs to be dropped without
 coordination seems to me to be a burden on rawhide users, but I don't
 think a single flag day would be problematic.

 I would expect the first flag day to be busy.  I see 756 Epoch: tags
 currently, though 161 are set to 0 for whatever reason.  Afterwards I
 would expect no more than a small number of packages per cycle to
 acquire Epoch: tags.

  - J<
>>> If DNF were helpful and was able to report packages, which has higher
>>> NVR then E(NVR),
>>
>> I meant (E)NVR actually.
>>
>>
>> V.
>>
>>
>>> then I can imagine that reset of epoch could work.
>>> Otherwise I am against resetting epochs.
>>>
> I'm confused, why would that matter? And DNF always reports NEVRA...
>
>

The epoch are used in cases like:

1. There is  foo version 1.0

2. foo is updated to version 2.0, because it seems it is safe.

3. It is discovered, that it breaks stuff, so the decision is go back to
1.0 and add epoch.

4. Eventually, we really want to have 2.0 in the release or even
something newer. Now, the epoch could be removed, but it is not
possible, because it has the highest priority.


In this case, if DNF said something like "you have installed foo-1:1.0,
but there is available foo-0:2.0" it would give me hint. From the start
it would be annoying, but once we would reach the point 4, I would, at
least, know that I should do distrosync or something.


V.

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

Re: Schedule for Monday's FESCo Meeting (2019-03-11)

[Petr Šabata]

On Mon, Mar 11, 2019 at 09:56:35AM +0100, Petr Šabata wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
> irc.freenode.net.
> 
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
> 
> or run:
>   date -d '2019-03-11 15:00 UTC'

Note the meeting is scheduled in UTC, so if you just switched
to DST, the meeting time changed for you.

P


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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Monday's FESCo Meeting (2019-03-11)

[Petr Šabata]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-03-11 15:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =
F31 System-Wide Change: Move Gold Into A SubpackageOf Binutils
https://pagure.io/fesco/issue/2097
ACCEPTED (+5, 0, -0)

F31 System-Wide Change: Automatic strict inter-package dependencies
https://pagure.io/fesco/issue/2095
ACCEPTED (+4, 0, -0)

F31 System-Wide Change: Python 3.8
https://pagure.io/fesco/issue/2093
ACCEPTED (+8, 0, -0)

require a re-review to unretire packages after 8 weeks instead of 2 weeks
https://pagure.io/fesco/issue/2089
ACCEPTED (+5, 0, -0)

= Followups =

#topic #2096 F31 System-Wide Change: BuildRequires generators
.fesco 2096
https://pagure.io/fesco/issue/2096

#topic #2092 Fedora 31 schedule
.fesco 2092
https://pagure.io/fesco/issue/2092

= New business =

#topic #2101 Fedora 30 incomplete changes
.fesco 2101
https://pagure.io/fesco/issue/2101

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 


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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Rawhide-20190310.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Compose FAILS proposed Rawhide gating check!
10 of 47 required tests failed, 7 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: 26/141 (x86_64), 4/24 (i386), 1/2 (arm)

ID: 361067  Test: x86_64 Server-dvd-iso server_firewall_default **GATING**
URL: https://openqa.fedoraproject.org/tests/361067
ID: 361069  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/361069
ID: 361073  Test: x86_64 Server-dvd-iso server_cockpit_default **GATING**
URL: https://openqa.fedoraproject.org/tests/361073
ID: 361086  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/361086
ID: 361091  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/361091
ID: 361098  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/361098
ID: 361101  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/361101
ID: 361105  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/361105
ID: 361106  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/361106
ID: 361109  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/361109
ID: 361118  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/361118
ID: 361121  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/361121
ID: 361160  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/361160
ID: 361163  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/361163
ID: 361164  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/361164
ID: 361165  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/361165
ID: 361188  Test: x86_64 universal install_kickstart_firewall_configured 
**GATING**
URL: https://openqa.fedoraproject.org/tests/361188
ID: 361191  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/361191
ID: 361192  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/361192
ID: 361193  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/361193
ID: 361194  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/361194
ID: 361195  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/361195
ID: 361196  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/361196
ID: 361197  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/361197
ID: 361198  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/361198
ID: 361199  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/361199
ID: 361200  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/361200
ID: 361201  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/361201
ID: 361219  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/361219
ID: 361220  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/361220
ID: 361221  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/361221

Soft failed openQA tests: 61/141 (x86_64), 18/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 361053  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/361053
ID: 361054  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/361054
ID: 361055  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/361055
ID: 361056  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/361056
ID: 361062  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/361062
ID: 361063  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/361063
ID: 361074  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: 

Re: Can't push to batched an Fedora 30 update?

[Alexander Ploumistos]

On Mon, Mar 11, 2019 at 9:23 AM Richard W.M. Jones  wrote:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-fd699ee2ea
>
> "This update has reached 3 days in testing and can be pushed to stable
> now if the maintainer wishes"
>
> Yes I'd like to, but there's no push to batched button!
> I guess this is something to do with "Failed to talk to Greenwave."?

Beta Freeze:
https://fedoraproject.org/wiki/Milestone_freezes
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Can't push to batched an Fedora 30 update?

[Richard W.M. Jones]

https://bodhi.fedoraproject.org/updates/FEDORA-2019-fd699ee2ea

"This update has reached 3 days in testing and can be pushed to stable
now if the maintainer wishes"

Yes I'd like to, but there's no push to batched button!
I guess this is something to do with "Failed to talk to Greenwave."?

Rich.

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

[Bug 1687197] perl-ExtUtils-Manifest-1.72 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-ExtUtils-Manifest-1.72-1.fc29 has been submitted as an update to Fedora
29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a0f9360b0e

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687197] perl-ExtUtils-Manifest-1.72 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-ExtUtils-Manifest-1.72-1.fc30 has been submitted as an update to Fedora
30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b77433ca26

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687197] perl-ExtUtils-Manifest-1.72 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-ExtUtils-Manifest-1.72
   ||-1.fc31



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 29.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687224] perl-Sub-Quote-2.006003 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Sub-Quote-2.006003-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-daa3316272

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687224] perl-Sub-Quote-2.006003 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Sub-Quote-2.006003-1.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-a5bb214d07

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687224] perl-Sub-Quote-2.006003 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Sub-Quote-2.006003-1.f
   ||c31



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687209] perl-strictures-2.000006 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-strictures-2.06-4.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9f5f97349f

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687209] perl-strictures-2.000006 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-strictures-2.06-4.
   ||fc31



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1687254] perl-DBIx-Class-DeploymentHandler-0.002226 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-DBIx-Class-DeploymentH |perl-DBIx-Class-DeploymentH
   |andler-0.002226 is  |andler-0.002227 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.002227
Current version/release in rawhide: 0.002224-1.fc31
URL: http://search.cpan.org/dist/DBIx-Class-DeploymentHandler

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/8029/

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org