date:20180822


On 23.8.2018 00:31, Artur Iwicki wrote:

If we remove the Group: tag from existing packages (assuming 100% accuracy), 
this would mean that the only way for a package to have the Group: tag would be 
to:
a) have a maintainer add it back in
b) accept a new package with the Group: tag present

If we assume option a) to be unlikely, then wouldn't it make more sense to put the 
"doesn't have a Group: tag" check in fedora-review, instead of rpmlint?


That is high likely. We have usual suspect packages that remove all mass 
changes every time.


That said, I doubt their maintains would use rpmlint at all.

--
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/message/N54KW2BJHF4BY2PISZGRGAQMFYN2XJHH/

[Bug 1620308] New: perl-Archive-Zip-1.63 is available

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

Bug ID: 1620308
   Summary: perl-Archive-Zip-1.63 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Archive-Zip
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
john.j5l...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, mbar...@fastmail.com,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com, st...@silug.org



Latest upstream release: 1.63
Current version/release in rawhide: 1.62-1.fc30
URL: http://search.cpan.org/dist/Archive-Zip/

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

-- 
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/message/CPCY7YNXWJBX2GIHLKSGMUJXTK6DKVWT/

Intent to drop python2-behave


There is a cluster of PRs:

https://src.fedoraproject.org/rpms/python-behave/pull-request/2
https://src.fedoraproject.org/rpms/python-docx/pull-request/2
https://src.fedoraproject.org/rpms/python-parse_type/pull-request/2

That allows us to drop python2-behave as nothing will depend on it.

I'm giving one week notice here.
--
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/message/RWJM44UTDWGBOO6FNMBSCDC2GCLG7NFD/

Re: Mono - Do we have a maintainer?

2018-08-22 Thread Gerald Henriksen

On Wed, 22 Aug 2018 13:59:51 -0400, you wrote:

>* Dan Horák  [2018-08-22 03:55]:
>> a nice thing on Mono is that it is fully multi-arch, supporting all
>> Fedora arches. Won't be multi-arch problem for msbuild or .NET Core?
>
>Oh. Right, that would be a problem. .NET Core upstream essentially
>supports x86_64 only. arm-hfp, aarch64 and x86 are supported to some
>extent. Every other platform is pretty much unsupported.

As of .Net Core 2.1 Arm32 is officially supported.

https://blogs.msdn.microsoft.com/dotnet/2018/05/30/announcing-net-core-2-1/
___
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/message/P5KACXUM4UKXJCKVOIBXJTLHMRKWT63E/

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-22 Thread Mikolaj Izdebski

On 08/23/2018 12:31 AM, Artur Iwicki wrote:
> If we remove the Group: tag from existing packages (assuming 100% accuracy), 
> this would mean that the only way for a package to have the Group: tag would 
> be to:
> a) have a maintainer add it back in
> b) accept a new package with the Group: tag present
> 
> If we assume option a) to be unlikely, 

Oh, don't assume anything like that.  Some maintainers (mentioned on
this list in other threads earlier) have proven record of re-adding
Group after removal.

> then wouldn't it make more sense to put the "doesn't have a Group: tag" check 
> in fedora-review, instead of rpmlint?

Fedora-Review doesn't need to be run during package review. It's not
even recommended in review guidelines. On the other hand running rpmlint
is mandatory, it's the very first MUST item in the guidelines.

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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/message/GLBWOUMW4MQVA4RT2HLIQVSRCJM65CRT/

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-22 Thread Artur Iwicki

If we remove the Group: tag from existing packages (assuming 100% accuracy), 
this would mean that the only way for a package to have the Group: tag would be 
to:
a) have a maintainer add it back in
b) accept a new package with the Group: tag present

If we assume option a) to be unlikely, then wouldn't it make more sense to put 
the "doesn't have a Group: tag" check in fedora-review, instead of rpmlint?
___
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/message/53QWKJZPB325VSAWBMLBM2O46HYW63VE/

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-22 Thread Neal Gompa

On Wed, Aug 22, 2018 at 6:00 PM Omair Majid  wrote:
>
> * Ben Cotton  [2018-08-22 16:38]:
> > 9420 source packages (43% of the total count) come closer to
> > compliance with Fedora's packaging guidelines.  The Group: tag has
> > been in a "should not use" state since March of 2017.
>
> Can rpmlint be patched to warn about using the 'Group:' tag?
>

If it's wanted downstream, maybe. But every distro aside from Fedora
uses the Group tag properly, so I will not make such a change
upstream.



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

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-22 Thread Jason L Tibbitts III

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> Can we patch rpm not to show this useless line?

In the context of what I wrote, there's no "useless line".  I assume
you're talking about rpm -qi output, but I was being more general than
that.  Certainly we wouldn't patch out the GROUP querytag, for example,
or change the RPM header format.  The group field in the header will
always contain some data, and if the specfile didn't specify a group
then 'Unspecified' will be stored there.

Now, the 'rpm -qi' output is actually something you can change.  It's
defined in /usr/lib/rpm/rpmpopt-(version).  I have no idea if the Fedora
RPM maintainers, or upstream RPM, would be willing to patch that file,
since it can show valid info and Fedora isn't the only place where
people might acquire packages.  Plus I figure that if anyone really
cared about what was shown there, we would have patched out the
'Relocations:' line about a decade ago.  Really, 'dnf info' output is
probably more relevant at this point.

However, if you really don't want to see it, you can just put an 'rpm
alias --info' line in /etc/popt or ~/.popt.  I don't believe that RPM
query expressions are sufficiently powerful to suppress the Group: line
if the group is 'Unspecified', but I'd be happy if I were wrong.

rpm alias --info --qf '\
Name: %{NAME}\n\
%|EPOCH?{Epoch   : %{EPOCH}\n}|\
Version : %{VERSION}\n\
Release : %{RELEASE}\n\
Architecture: %{ARCH}\n\
Install Date: %|INSTALLTIME?{%{INSTALLTIME:date}}:{(not installed)}|\n\
Size: %{LONGSIZE}\n\
%|LICENSE?{License : %{LICENSE}}|\n\
Signature   : 
%|DSAHEADER?{%{DSAHEADER:pgpsig}}:{%|RSAHEADER?{%{RSAHEADER:pgpsig}}:{%|SIGGPG?{%{SIGGPG:pgpsig}}:{%|SIGPGP?{%{SIGPGP:pgpsig}}:{(none)}|}|}|}|\n\
Source RPM  : %{SOURCERPM}\n\
Build Date  : %{BUILDTIME:date}\n\
Build Host  : %{BUILDHOST}\n\
Relocations : %|PREFIXES?{[%{PREFIXES} ]}:{(not relocatable)}|\n\
%|PACKAGER?{Packager: %{PACKAGER}\n}|\
%|VENDOR?{Vendor  : %{VENDOR}\n}|\
%|URL?{URL : %{URL}\n}|\
%|BUGURL?{Bug URL : %{BUGURL}\n}|\
Summary : %{SUMMARY}\n\
Description :\n%{DESCRIPTION}\n' \
--POPTdesc=$"list descriptive information from package(s)"

 - 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/message/STWLNXEFU3VJ6C6ETBX42FQURMOCETSK/

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-22 Thread Omair Majid

* Ben Cotton  [2018-08-22 16:38]:
> 9420 source packages (43% of the total count) come closer to
> compliance with Fedora's packaging guidelines.  The Group: tag has
> been in a "should not use" state since March of 2017.

Can rpmlint be patched to warn about using the 'Group:' tag?

Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
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/message/MIO2QYB45WML6NED7GLMQ5UDROFPF57V/

Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

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

== Summary ==
Remove the Group: tag from over 9000 source packages.

== Owner ==
* Name: Jason Tibbitts (tibbs)
* Email: ti...@math.uh.edu

== Detailed Description ==
I will remove the Group: tag from all specfiles in Fedora dist-git
which still have it, verify that the result is syntactically correct,
then commit and push the change.  Since this is a relatively minor
changeI am not planning to bump Release: or add %changelog entries,
but I do that if it is deemed necessary.

I am proposing this as an official change instead of just doing it (as
with other low risk packaging cleanups) because:
* It would be by far the largest mass package change we would ever
have attempted.
* It does technically cause a visible change in the resulting package.
If queried, rpm will show the group as "Unspecified" for every binary
package in the distribution instead of just the majority of them.  It
is theoretically possible that someone could have a tool which uses
this information, although that tool most already be mostly useless.
* People would yell at me even more loudly if I posted the full 9000+
package and maintainer listing.

Since this changes many, many packages and has small but nonzero end
user visibility I am filing this as a system-wide change.

== Benefit to Fedora ==
9420 source packages (43% of the total count) come closer to
compliance with Fedora's packaging guidelines.  The Group: tag has
been in a "should not use" state since March of 2017.

More useless cruft is removed from specfiles.  This provides a slight
benefit to ease of maintenance and eliminates yet another bizarre
historical relic which confuses new packagers.  Cargo cult behavior is
rampant and removing the cruft in one go will be another step towards
having system-wide clean specfiles.

The Group: tag is not required in any live Fedora or EPEL release.
RHEL5 did need it, but EPEL5 did not as it was supplied automatically
via magic in the epel-rpm-macros package.  The
[[Packaging:Guidelines#Tags_and_Sections|Packaging Guidelines]] have
indicated that the Group: tag should not be used since March of 2017.

The tag is not used by Fedora currently; the concept was replaced long
ago by comps which permits a far more flexible classification of
packages.  dnf has a "group" subcommand but this operates on comps
groups, not anything defined by the Group: tag.  dnf does not display
information from Group: tag.  If a package does include a Group: tag,
a direct rpm query will display it but otherwise will show
"Unspecified".

There was never any strong standard for the contents of the Group:
tag.  Older versions of rpm (still present in RHEL7 but not in any
live Fedora release) contained a documentation file named GROUPS with
a list and rpmlint would check this, but it was never strongly adhered
to.  The current package set has some quality examples like a Group
tag containing the string "Group:" and one containing only
"evelopment/Languages".  It seems relatively obvious that nobody is
paying attention or making use of that data.

Among the tags which are at least in the recommended set which rpm
used to have, most do not convey particularly useful information.  Of
the Group: tags which remain, 5438 contain "Development/Libraries",
1871 have "System Environment/Libraries" and 1346 are
"Development/Languages".

== Scope ==
* Proposal owners: Whip up a quick script, test it well to ensure that
it doesn't have unintended side effects, and handle outliers or
special cases manually.  Then wait a few hours to push commits to
9000+ repositories.

* Other developers: Nothing besides dealing with any commit emails they receive.

* Release engineering:  There should be no releng involvement.  There
is no real need for any packages to be rebuilt.  If there is an F30
rebuild scheduled, it would be advantageous for this change to be made
before that happens.  I filed [https://pagure.io/releng/issue/7627] in
any case.

** 
[[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: There should be no change to deliverables besides
the fact that the packages no longer have Group: tags.

* Policies and guidelines: This is implementing a requirement of the
current packaging guidelines.  The specific change mandating this
happened in March of 2017.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
There is no effect on upgrades.  Packagers have always been free to
remove Group: tags, even within a stable release.  This will simply
result in the rest of them going away.

== How To Test ==
There is not much to test.  The change is simple and so if done with a
modicum of care it will not cause syntax errors in the packages.
Testers and maintainers can of course do local or koji builds after
the changes have been pushed to ensure that there are no problems, and
rpm -qip run on the resulting binary packages should only show Group:

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-22 Thread Tom Stellard

On 08/22/2018 01:28 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Remove_Group_Tag
> 
> == Summary ==
> Remove the Group: tag from over 9000 source packages.
> 
> == Owner ==
> * Name: Jason Tibbitts (tibbs)
> * Email: ti...@math.uh.edu
> 
> == Detailed Description ==
> I will remove the Group: tag from all specfiles in Fedora dist-git
> which still have it, verify that the result is syntactically correct,
> then commit and push the change.  Since this is a relatively minor
> changeI am not planning to bump Release: or add %changelog entries,
> but I do that if it is deemed necessary.
> 
> I am proposing this as an official change instead of just doing it (as
> with other low risk packaging cleanups) because:
> * It would be by far the largest mass package change we would ever
> have attempted.
> * It does technically cause a visible change in the resulting package.
> If queried, rpm will show the group as "Unspecified" for every binary
> package in the distribution instead of just the majority of them.  It
> is theoretically possible that someone could have a tool which uses
> this information, although that tool most already be mostly useless.
> * People would yell at me even more loudly if I posted the full 9000+
> package and maintainer listing.
> 
> Since this changes many, many packages and has small but nonzero end
> user visibility I am filing this as a system-wide change.
> 
> == Benefit to Fedora ==
> 9420 source packages (43% of the total count) come closer to
> compliance with Fedora's packaging guidelines.  The Group: tag has
> been in a "should not use" state since March of 2017.
> 
> More useless cruft is removed from specfiles.  This provides a slight
> benefit to ease of maintenance and eliminates yet another bizarre
> historical relic which confuses new packagers.  Cargo cult behavior is
> rampant and removing the cruft in one go will be another step towards
> having system-wide clean specfiles.
> 
> The Group: tag is not required in any live Fedora or EPEL release.
> RHEL5 did need it, but EPEL5 did not as it was supplied automatically
> via magic in the epel-rpm-macros package.  The
> [[Packaging:Guidelines#Tags_and_Sections|Packaging Guidelines]] have
> indicated that the Group: tag should not be used since March of 2017.
> 
> The tag is not used by Fedora currently; the concept was replaced long
> ago by comps which permits a far more flexible classification of
> packages.  dnf has a "group" subcommand but this operates on comps
> groups, not anything defined by the Group: tag.  dnf does not display
> information from Group: tag.  If a package does include a Group: tag,
> a direct rpm query will display it but otherwise will show
> "Unspecified".
> 
> There was never any strong standard for the contents of the Group:
> tag.  Older versions of rpm (still present in RHEL7 but not in any
> live Fedora release) contained a documentation file named GROUPS with
> a list and rpmlint would check this, but it was never strongly adhered
> to.  The current package set has some quality examples like a Group
> tag containing the string "Group:" and one containing only
> "evelopment/Languages".  It seems relatively obvious that nobody is
> paying attention or making use of that data.
> 
> Among the tags which are at least in the recommended set which rpm
> used to have, most do not convey particularly useful information.  Of
> the Group: tags which remain, 5438 contain "Development/Libraries",
> 1871 have "System Environment/Libraries" and 1346 are
> "Development/Languages".
> 
> == Scope ==
> * Proposal owners: Whip up a quick script, test it well to ensure that
> it doesn't have unintended side effects, and handle outliers or
> special cases manually.  Then wait a few hours to push commits to
> 9000+ repositories.
> 

If I run: vim foo.spec on Rawhide, it will create a spec template which includes
the Group tag, so this should be updated too.

-Tom

> * Other developers: Nothing besides dealing with any commit emails they 
> receive.
> 
> * Release engineering:  There should be no releng involvement.  There
> is no real need for any packages to be rebuilt.  If there is an F30
> rebuild scheduled, it would be advantageous for this change to be made
> before that happens.  I filed [https://pagure.io/releng/issue/7627] in
> any case.
> 
> ** 
> [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
> of deliverables]]: There should be no change to deliverables besides
> the fact that the packages no longer have Group: tags.
> 
> * Policies and guidelines: This is implementing a requirement of the
> current packaging guidelines.  The specific change mandating this
> happened in March of 2017.
> 
> * Trademark approval: N/A (not needed for this Change)
> 
> == Upgrade/compatibility impact ==
> There is no effect on upgrades.  Packagers have always been free to
> remove Group: tags, even within a stable release.  This will simply
> result in the rest of

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-22 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Aug 22, 2018 at 04:28:16PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Remove_Group_Tag
> 
> == Summary ==
> Remove the Group: tag from over 9000 source packages.
> 
> == Owner ==
> * Name: Jason Tibbitts (tibbs)
> * Email: ti...@math.uh.edu
> 
> == Detailed Description ==
> I will remove the Group: tag from all specfiles in Fedora dist-git
> which still have it, verify that the result is syntactically correct,
> then commit and push the change.  Since this is a relatively minor
> changeI am not planning to bump Release: or add %changelog entries,
> but I do that if it is deemed necessary.
> 
> I am proposing this as an official change instead of just doing it (as
> with other low risk packaging cleanups) because:
> * It would be by far the largest mass package change we would ever
> have attempted.
> * It does technically cause a visible change in the resulting package.
> If queried, rpm will show the group as "Unspecified"
Can we patch rpm not to show this useless line?

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/message/VJBTHIYJ4H4SMV3BEPMIPRXTEWWWC6WI/

Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

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

== Summary ==
Remove the Group: tag from over 9000 source packages.

== Owner ==
* Name: Jason Tibbitts (tibbs)
* Email: ti...@math.uh.edu

== Detailed Description ==
I will remove the Group: tag from all specfiles in Fedora dist-git
which still have it, verify that the result is syntactically correct,
then commit and push the change.  Since this is a relatively minor
changeI am not planning to bump Release: or add %changelog entries,
but I do that if it is deemed necessary.

I am proposing this as an official change instead of just doing it (as
with other low risk packaging cleanups) because:
* It would be by far the largest mass package change we would ever
have attempted.
* It does technically cause a visible change in the resulting package.
If queried, rpm will show the group as "Unspecified" for every binary
package in the distribution instead of just the majority of them.  It
is theoretically possible that someone could have a tool which uses
this information, although that tool most already be mostly useless.
* People would yell at me even more loudly if I posted the full 9000+
package and maintainer listing.

Since this changes many, many packages and has small but nonzero end
user visibility I am filing this as a system-wide change.

== Benefit to Fedora ==
9420 source packages (43% of the total count) come closer to
compliance with Fedora's packaging guidelines.  The Group: tag has
been in a "should not use" state since March of 2017.

More useless cruft is removed from specfiles.  This provides a slight
benefit to ease of maintenance and eliminates yet another bizarre
historical relic which confuses new packagers.  Cargo cult behavior is
rampant and removing the cruft in one go will be another step towards
having system-wide clean specfiles.

The Group: tag is not required in any live Fedora or EPEL release.
RHEL5 did need it, but EPEL5 did not as it was supplied automatically
via magic in the epel-rpm-macros package.  The
[[Packaging:Guidelines#Tags_and_Sections|Packaging Guidelines]] have
indicated that the Group: tag should not be used since March of 2017.

The tag is not used by Fedora currently; the concept was replaced long
ago by comps which permits a far more flexible classification of
packages.  dnf has a "group" subcommand but this operates on comps
groups, not anything defined by the Group: tag.  dnf does not display
information from Group: tag.  If a package does include a Group: tag,
a direct rpm query will display it but otherwise will show
"Unspecified".

There was never any strong standard for the contents of the Group:
tag.  Older versions of rpm (still present in RHEL7 but not in any
live Fedora release) contained a documentation file named GROUPS with
a list and rpmlint would check this, but it was never strongly adhered
to.  The current package set has some quality examples like a Group
tag containing the string "Group:" and one containing only
"evelopment/Languages".  It seems relatively obvious that nobody is
paying attention or making use of that data.

Among the tags which are at least in the recommended set which rpm
used to have, most do not convey particularly useful information.  Of
the Group: tags which remain, 5438 contain "Development/Libraries",
1871 have "System Environment/Libraries" and 1346 are
"Development/Languages".

== Scope ==
* Proposal owners: Whip up a quick script, test it well to ensure that
it doesn't have unintended side effects, and handle outliers or
special cases manually.  Then wait a few hours to push commits to
9000+ repositories.

* Other developers: Nothing besides dealing with any commit emails they receive.

* Release engineering:  There should be no releng involvement.  There
is no real need for any packages to be rebuilt.  If there is an F30
rebuild scheduled, it would be advantageous for this change to be made
before that happens.  I filed [https://pagure.io/releng/issue/7627] in
any case.

** 
[[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: There should be no change to deliverables besides
the fact that the packages no longer have Group: tags.

* Policies and guidelines: This is implementing a requirement of the
current packaging guidelines.  The specific change mandating this
happened in March of 2017.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
There is no effect on upgrades.  Packagers have always been free to
remove Group: tags, even within a stable release.  This will simply
result in the rest of them going away.

== How To Test ==
There is not much to test.  The change is simple and so if done with a
modicum of care it will not cause syntax errors in the packages.
Testers and maintainers can of course do local or koji builds after
the changes have been pushed to ensure that there are no problems, and
rpm -qip run on the resulting binary packages should only show Group:

Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot

== Summary ==
glibc-minimal-langpack is added to @Buildsystem group and installed
into the minimal buildroot instead of glibc-all-langpacks. Packages
which need more locales than plain C/C.UTF-8/POSIX need to pull them
in through BuildRequires.

== Owner ==
* Name: Zbigniew Jędrzejewski-Szmek (zbyszek)
* Email: zbys...@in.waw.pl

== Detailed Description ==

Right now glibc-all-langpacks is installed in buildroots (mock, koji,
…).
It is 24 MB, out of the total of 145 MB. Replacing it with
glibc-minimal-langpack,
which has negligible size, decreases the buildroot size by 17%.

glibc Requires glibc-langpack, and Suggests glibc-all-langpacks, so it
gets installed automatically to satisfy that dependency. If a
different
package providing glibc-langpack is installed, glibc-all-langpacks is
skipped.

This change is basically adding glibc-minimal-langpack to @Buildsystem
in comps and fixing any fallout in packages.

A quick grep over spec files reveals:
```
$ rg -l 'LC_CTYPE=[^C]' *.spec | wc -l
11
$ rg -l 'LC_ALL=[^C]' *.spec | wc -l
42
```
that there are at least ~50 packages which need adjustment. They can
be either switched over to C.UTF-8 or a BuildRequires can be added.

== Benefit to Fedora ==

The minimal buildroot becomes smaller, making builds slightly faster.

== Scope ==
* Proposal owners:
** adjust comps
** fix packages which can be identified without rebuilding (see grep
output above)
** fix fallout in the mass rebuild if anything is missed above

* Other developers: report breakage and/or fix their own packages

* Release engineering: [https://pagure.io/releng/issue/7610 #7610]

* Policies and guidelines: no changes needed
(The Packaging Guidelines already specify that all necessary
dependencies must be declared using BuildRequires.)

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
This only affect package building process, so it has no end-user impact.

== How To Test ==
Verify that packages still build after the comps change.

== User Experience ==
Not visible to end-users.

== Dependencies ==
None.

== Contingency Plan ==
Revert the comps change. Any changes in packages would be backwards
compatible, so there's no need to revert them. There is also no need
to rebuild any packages already successfully built.

* Contingency mechanism: remove glibc-minimal-langpack from @Buildsystem
* Blocks release? not directly, but if packages fail to build, it
would be problem
* Blocks product? no

== Documentation ==
None

-- 
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/message/WSV6XZGC24EJGHWVKG63OOJQFDZ6ITP6/

Fedora 30 System-Wide Change proposal: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE

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

== Summary ==
Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double ABI.

== Owner ==
* Name: Carlos O'Donell (codonell)
* Email: car...@redhat.com

== Detailed Description ==
IBM has designed a new long double ABI that adheres to the 128-bit
IEEE format. This format is more standard than the existing AIX
double-double or IBM long double (2 grouped 64-bit doubles) which has
discontinuous mantissas and is difficult for developers to use. In
Fedora 29 the plan is to switch to the new ABI for long double, while
still supporting old applications via compatibility symbols. Newly
compiled applications use either the old or new ABI but not a mix of
both. Changes are required in the core C libraries, and the compiler
and the compiler runtimes including the C++ standard libraries.
Therefore there is coordination required across the core toolchain
componenents e.g. gcc, binutils, glibc, gdb (to debug the new types).

== Benefit to Fedora ==
Fedora developers will be using a standard 128-bit IEEE format for
long double instead of the non-standard double-double AIX format which
has a discontinuous mantissa and multiple representations for the same
value.

== Scope ==
The change is relatively limited in that not many packages use the
long double floating point ABI. The double floating point ABI is much
more used, but not long double. It is estimated that few packages use
long double directly, and those packages will need to be rebuilt in
order to use the new ABI. This rebuilding can be targetted by
analyzing which packages have long double usage in their debug
information and rebuilding just those packages. However, we plan to
just use the existing mass rebuild for glibc 2.29 to handle this
issue.

* Proposal owners: Transition glibc to float128 format for long double
for IBM ppc64le. Transition gcc to the default for long double.
Implement support for the new long double format in
libstdc++. Ensure gdb can handle the new types.
* Other developers: Developers need to ensure that rawhide is stable
and ready for the Fedora 30 branch.
* Release engineering: A mass rebuild request has been filed for the
parent system-wide change to upgrade glibc to
2.29[https://pagure.io/releng/issue/7475 #7475]
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: Not needed for this change

== Upgrade/compatibility impact ==
The library and language runtimes are backwards compatible with the
version shipped in Fedora.

We fully expect to fix all packaging changes in Fedora Rawhide first
when everything is ready.

== How To Test ==
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has 2500+ tests that run to verify the
correct operation of the library. In the future we'll also be running
the microbenchmark to look for performance regressions as well as
behavioural ones.

Specific testing for 128-bit IEEE long double ABI will be carried out
by the glibc testsuite. Integration smoke testing will be carried out
by the glibc developers to make sure new applications are built with
the correct defaults and work as expected.

Specific testing for 128-bit IEEE long double ABI will be carried out
by the gcc testsuite.

Specific smoke testing will be carried out using gdb to read and write
the new types.

== User Experience ==
Users will see a new 128-bit floating point ABI, but this will largely
be transparent to them. On POWER hardware that supports 128-bit long
double in hardware the compiler will use the hardware transparently to
accelerate floating point operations, otherwise software floating
point emulation will be used.

== Dependencies ==
This change requires coordination of glibc and gcc to change the
compiler defaults and build the compiler language runtimes correctly.
Also gdb must be able to support the new type to make the process of
transition seamless.

== Contingency Plan ==
* Contingency mechanism: Ship glibc 2.28 instead of glibc 2.29, or
ship glibc 2.29 without this feature if it is not ready.

* Contingency deadline: Final mass rebuild before Fedora release.
* Blocks release? Upgrading glibc does block the release. We should
not ship without the float128 ABI change.

== Documentation ==
The glibc/gcc manual contain the documentation for the release and
don't need any more additional work.

== Release Notes ==
* The ppc64le architecture changed the format of the long
double type to binary128. (Previously, a pair of two doubles
was used.)

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

Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot

== Summary ==
glibc-minimal-langpack is added to @Buildsystem group and installed
into the minimal buildroot instead of glibc-all-langpacks. Packages
which need more locales than plain C/C.UTF-8/POSIX need to pull them
in through BuildRequires.

== Owner ==
* Name: Zbigniew Jędrzejewski-Szmek (zbyszek)
* Email: zbys...@in.waw.pl

== Detailed Description ==

Right now glibc-all-langpacks is installed in buildroots (mock, koji,
…).
It is 24 MB, out of the total of 145 MB. Replacing it with
glibc-minimal-langpack,
which has negligible size, decreases the buildroot size by 17%.

glibc Requires glibc-langpack, and Suggests glibc-all-langpacks, so it
gets installed automatically to satisfy that dependency. If a
different
package providing glibc-langpack is installed, glibc-all-langpacks is
skipped.

This change is basically adding glibc-minimal-langpack to @Buildsystem
in comps and fixing any fallout in packages.

A quick grep over spec files reveals:
```
$ rg -l 'LC_CTYPE=[^C]' *.spec | wc -l
11
$ rg -l 'LC_ALL=[^C]' *.spec | wc -l
42
```
that there are at least ~50 packages which need adjustment. They can
be either switched over to C.UTF-8 or a BuildRequires can be added.

== Benefit to Fedora ==

The minimal buildroot becomes smaller, making builds slightly faster.

== Scope ==
* Proposal owners:
** adjust comps
** fix packages which can be identified without rebuilding (see grep
output above)
** fix fallout in the mass rebuild if anything is missed above

* Other developers: report breakage and/or fix their own packages

* Release engineering: [https://pagure.io/releng/issue/7610 #7610]

* Policies and guidelines: no changes needed
(The Packaging Guidelines already specify that all necessary
dependencies must be declared using BuildRequires.)

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
This only affect package building process, so it has no end-user impact.

== How To Test ==
Verify that packages still build after the comps change.

== User Experience ==
Not visible to end-users.

== Dependencies ==
None.

== Contingency Plan ==
Revert the comps change. Any changes in packages would be backwards
compatible, so there's no need to revert them. There is also no need
to rebuild any packages already successfully built.

* Contingency mechanism: remove glibc-minimal-langpack from @Buildsystem
* Blocks release? not directly, but if packages fail to build, it
would be problem
* Blocks product? no

== Documentation ==
None

-- 
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/message/WSV6XZGC24EJGHWVKG63OOJQFDZ6ITP6/

Fedora 30 Self-Contained Change proposal: No more automagic Python bytecompilation (phase 2)

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

== Summary ==
See 
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation
Now we are changing the default to be %global
_python_bytecompile_extra 0.

== Owner ==
* Name: Miro Hrončok (Churchyard)
* Name: Petr Viktorin (pviktori)
* Email: mhron...@redhat.com, pvikt...@redhat.com

== Detailed Description ==

See thed etailed Description of the previous Change Proposal:
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation#Detailed_Description

We will now set %_python_bytecompile_extra to
0 by default.

All packages that ship Python 3 bytecode outside of Python 3
directories should be preferably converted to use
%py_byte_compile, but if they are not, it's fine.

We'll check all pyc/pyo files shipped by packages. We'll check if
those are explicitly compiled using %py_byte_compile. If
not, we mass push `%global _python_bytecompile_extra 1` to the package
specs to make them work. It's up the package maintainers to adjust the
package to the new style (or keep the line forever).

== Benefit to Fedora ==
See 
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation#Benefit_to_Fedora

== Scope ==
* Proposal owners: Change the default, slightly change the guidelines,
get the list of packages, push the change into them.

* Other developers: Maintainers of python3 packages are encouraged to
change their packages to use explicit %py_byte_compile
(not a System Wide Change, they don't have to do anything).

* Policies and guidelines: will be changed as described in description

== Upgrade/compatibility impact ==
None expected.

== How To Test ==
N/A

== User Experience ==
The users of this change are packagers. The new behavior should make
byte-compilation more obvious, explicit, and discoverable.
Users of Fedora should not feel this (except if this change uncovers a
packaging bug).

== Contingency Plan ==
* Contingency mechanism: we'll finish the change later (not a System
Wide Change)

== Documentation ==
The guidelines will be the documentation.

== Release Notes ==
This change does not deserve Release Notes, it is not user facing.


-- 
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/message/GBASVMDCUBEZ2O2LQVJC4AR454A4CML7/

Fedora 30 Self-Contained Change proposal: Make ambiguous python shebangs error

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

== Summary ==
The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot
policy script will be changed to make the build fail when it sees an
ambiguous python shebang, such as #!/usr/bin/python or
#!/usr/bin/env python. (The script has been warning in
these cases for 2 Fedora releases already, saying ''This will become
an ERROR''.)

== Owner ==
* Name: Miro Hrončok (churchyard)
* Email: 

== Detailed Description ==
The buildroot policy script in
/usr/lib/rpm/redhat/brp-mangle-shebangs currently changes
all python shebangs to python2 with a message like:

 *** WARNING: mangling shebang in /usr/bin/taskotron_result from
#!/usr/bin/python to #!/usr/bin/python2. This will become an ERROR,
fix it manually!

We will change it to:

  *** ERROR: ambiguous python shebang in
/usr/bin/taskotron_result: #!/usr/bin/python. Change it to python3 (or
python2) explicitly.

The script will exit with nonzero exit code, rendering the build failed.

The warning and a promise of the error was there for 2 releases (28
and 29). Taskotron check was also present.

There are standard mechanics to avoid this buildroot policy script or
to block certain files form it. Those remain intact by this change.
For details see
https://fedoraproject.org/wiki/Packaging:Guidelines#Shebang_lines and
https://fedoraproject.org/wiki/Packaging:Guidelines#BRP_.28BuildRoot_Policy.29_Scripts
sections of the packaging guidelines.

== Benefit to Fedora ==
Packagers will be notified by build error if they accidentally have
python2 shebangs (and python2 dependency) they didn't anticipate. It's
up to them to decide what to do with such files, no automation can
know.

== Scope ==
* Proposal owners: change the script, change Python Packaging
Guidelines 
(https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes)

* Other developers: fix their packages if they fail because of this
* Policies and guidelines: Adjust Python Packaging Guidelines
(https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes)
slightly.

* Trademark approval: N/A (not needed for this Change)

== How To Test ==
Have an RPM package that tries to ship files with ambiguous python
shebang. Observe the warning on Fedora 29 and the error on Fedora 30.

== User Experience ==
Users should not notice this, expect there might be less unneeded
python2 dependencies created by accident.

-- 
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/message/OLB7SKYB4HEHEX4CRPOYPETWD766CT64/

Fedora 30 System-Wide Change proposal: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE

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

== Summary ==
Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double ABI.

== Owner ==
* Name: Carlos O'Donell (codonell)
* Email: car...@redhat.com

== Detailed Description ==
IBM has designed a new long double ABI that adheres to the 128-bit
IEEE format. This format is more standard than the existing AIX
double-double or IBM long double (2 grouped 64-bit doubles) which has
discontinuous mantissas and is difficult for developers to use. In
Fedora 29 the plan is to switch to the new ABI for long double, while
still supporting old applications via compatibility symbols. Newly
compiled applications use either the old or new ABI but not a mix of
both. Changes are required in the core C libraries, and the compiler
and the compiler runtimes including the C++ standard libraries.
Therefore there is coordination required across the core toolchain
componenents e.g. gcc, binutils, glibc, gdb (to debug the new types).

== Benefit to Fedora ==
Fedora developers will be using a standard 128-bit IEEE format for
long double instead of the non-standard double-double AIX format which
has a discontinuous mantissa and multiple representations for the same
value.

== Scope ==
The change is relatively limited in that not many packages use the
long double floating point ABI. The double floating point ABI is much
more used, but not long double. It is estimated that few packages use
long double directly, and those packages will need to be rebuilt in
order to use the new ABI. This rebuilding can be targetted by
analyzing which packages have long double usage in their debug
information and rebuilding just those packages. However, we plan to
just use the existing mass rebuild for glibc 2.29 to handle this
issue.

* Proposal owners: Transition glibc to float128 format for long double
for IBM ppc64le. Transition gcc to the default for long double.
Implement support for the new long double format in
libstdc++. Ensure gdb can handle the new types.
* Other developers: Developers need to ensure that rawhide is stable
and ready for the Fedora 30 branch.
* Release engineering: A mass rebuild request has been filed for the
parent system-wide change to upgrade glibc to
2.29[https://pagure.io/releng/issue/7475 #7475]
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: Not needed for this change

== Upgrade/compatibility impact ==
The library and language runtimes are backwards compatible with the
version shipped in Fedora.

We fully expect to fix all packaging changes in Fedora Rawhide first
when everything is ready.

== How To Test ==
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has 2500+ tests that run to verify the
correct operation of the library. In the future we'll also be running
the microbenchmark to look for performance regressions as well as
behavioural ones.

Specific testing for 128-bit IEEE long double ABI will be carried out
by the glibc testsuite. Integration smoke testing will be carried out
by the glibc developers to make sure new applications are built with
the correct defaults and work as expected.

Specific testing for 128-bit IEEE long double ABI will be carried out
by the gcc testsuite.

Specific smoke testing will be carried out using gdb to read and write
the new types.

== User Experience ==
Users will see a new 128-bit floating point ABI, but this will largely
be transparent to them. On POWER hardware that supports 128-bit long
double in hardware the compiler will use the hardware transparently to
accelerate floating point operations, otherwise software floating
point emulation will be used.

== Dependencies ==
This change requires coordination of glibc and gcc to change the
compiler defaults and build the compiler language runtimes correctly.
Also gdb must be able to support the new type to make the process of
transition seamless.

== Contingency Plan ==
* Contingency mechanism: Ship glibc 2.28 instead of glibc 2.29, or
ship glibc 2.29 without this feature if it is not ready.

* Contingency deadline: Final mass rebuild before Fedora release.
* Blocks release? Upgrading glibc does block the release. We should
not ship without the float128 ABI change.

== Documentation ==
The glibc/gcc manual contain the documentation for the release and
don't need any more additional work.

== Release Notes ==
* The ppc64le architecture changed the format of the long
double type to binary128. (Previously, a pair of two doubles
was used.)

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

Fedora 30 Self-Contained Change proposal: Make ambiguous python shebangs error

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

== Summary ==
The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot
policy script will be changed to make the build fail when it sees an
ambiguous python shebang, such as #!/usr/bin/python or
#!/usr/bin/env python. (The script has been warning in
these cases for 2 Fedora releases already, saying ''This will become
an ERROR''.)

== Owner ==
* Name: Miro Hrončok (churchyard)
* Email: 

== Detailed Description ==
The buildroot policy script in
/usr/lib/rpm/redhat/brp-mangle-shebangs currently changes
all python shebangs to python2 with a message like:

 *** WARNING: mangling shebang in /usr/bin/taskotron_result from
#!/usr/bin/python to #!/usr/bin/python2. This will become an ERROR,
fix it manually!

We will change it to:

  *** ERROR: ambiguous python shebang in
/usr/bin/taskotron_result: #!/usr/bin/python. Change it to python3 (or
python2) explicitly.

The script will exit with nonzero exit code, rendering the build failed.

The warning and a promise of the error was there for 2 releases (28
and 29). Taskotron check was also present.

There are standard mechanics to avoid this buildroot policy script or
to block certain files form it. Those remain intact by this change.
For details see
https://fedoraproject.org/wiki/Packaging:Guidelines#Shebang_lines and
https://fedoraproject.org/wiki/Packaging:Guidelines#BRP_.28BuildRoot_Policy.29_Scripts
sections of the packaging guidelines.

== Benefit to Fedora ==
Packagers will be notified by build error if they accidentally have
python2 shebangs (and python2 dependency) they didn't anticipate. It's
up to them to decide what to do with such files, no automation can
know.

== Scope ==
* Proposal owners: change the script, change Python Packaging
Guidelines 
(https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes)

* Other developers: fix their packages if they fail because of this
* Policies and guidelines: Adjust Python Packaging Guidelines
(https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes)
slightly.

* Trademark approval: N/A (not needed for this Change)

== How To Test ==
Have an RPM package that tries to ship files with ambiguous python
shebang. Observe the warning on Fedora 29 and the error on Fedora 30.

== User Experience ==
Users should not notice this, expect there might be less unneeded
python2 dependencies created by accident.

-- 
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/message/OLB7SKYB4HEHEX4CRPOYPETWD766CT64/

Fedora 29-20180822.n.0 compose check report

2018-08-22 Thread Fedora compose checker

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Failed openQA tests: 19/130 (x86_64), 5/24 (i386), 1/2 (arm)

ID: 268290  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/268290
ID: 268291  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/268291
ID: 268302  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/268302
ID: 268306  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/268306
ID: 268315  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/268315
ID: 268316  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/268316
ID: 268317  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268317
ID: 268330  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268330
ID: 268331  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/268331
ID: 268334  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/268334
ID: 268335  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268335
ID: 268339  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/268339
ID: 268347  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/268347
ID: 268348  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/268348
ID: 268365  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/268365
ID: 268366  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/268366
ID: 268370  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/268370
ID: 268399  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/268399
ID: 268407  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/268407
ID: 268408  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/268408
ID: 268418  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/268418
ID: 268420  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/268420
ID: 268428  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/268428
ID: 268429  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/268429
ID: 268439  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/268439

Soft failed openQA tests: 68/130 (x86_64), 17/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 268284  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/268284
ID: 268285  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268285
ID: 268287  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/268287
ID: 268288  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268288
ID: 268297  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/268297
ID: 268303  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/268303
ID: 268304  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/268304
ID: 268310  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/268310
ID: 268311  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/268311
ID: 268312  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/268312
ID: 268313  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268313
ID: 268314  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/268314
ID: 268350  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/268350
ID: 268351  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/268351
ID: 268352  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/268352
ID: 268353  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/268353

Fedora 30 Self-Contained Change proposal: No more automagic Python bytecompilation (phase 2)

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

== Summary ==
See 
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation
Now we are changing the default to be %global
_python_bytecompile_extra 0.

== Owner ==
* Name: Miro Hrončok (Churchyard)
* Name: Petr Viktorin (pviktori)
* Email: mhron...@redhat.com, pvikt...@redhat.com

== Detailed Description ==

See thed etailed Description of the previous Change Proposal:
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation#Detailed_Description

We will now set %_python_bytecompile_extra to
0 by default.

All packages that ship Python 3 bytecode outside of Python 3
directories should be preferably converted to use
%py_byte_compile, but if they are not, it's fine.

We'll check all pyc/pyo files shipped by packages. We'll check if
those are explicitly compiled using %py_byte_compile. If
not, we mass push `%global _python_bytecompile_extra 1` to the package
specs to make them work. It's up the package maintainers to adjust the
package to the new style (or keep the line forever).

== Benefit to Fedora ==
See 
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation#Benefit_to_Fedora

== Scope ==
* Proposal owners: Change the default, slightly change the guidelines,
get the list of packages, push the change into them.

* Other developers: Maintainers of python3 packages are encouraged to
change their packages to use explicit %py_byte_compile
(not a System Wide Change, they don't have to do anything).

* Policies and guidelines: will be changed as described in description

== Upgrade/compatibility impact ==
None expected.

== How To Test ==
N/A

== User Experience ==
The users of this change are packagers. The new behavior should make
byte-compilation more obvious, explicit, and discoverable.
Users of Fedora should not feel this (except if this change uncovers a
packaging bug).

== Contingency Plan ==
* Contingency mechanism: we'll finish the change later (not a System
Wide Change)

== Documentation ==
The guidelines will be the documentation.

== Release Notes ==
This change does not deserve Release Notes, it is not user facing.


-- 
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/message/GBASVMDCUBEZ2O2LQVJC4AR454A4CML7/

Re: Mono - Do we have a maintainer?

2018-08-22 Thread Omair Majid

* Dan Horák  [2018-08-22 03:55]:
> a nice thing on Mono is that it is fully multi-arch, supporting all
> Fedora arches. Won't be multi-arch problem for msbuild or .NET Core?

Oh. Right, that would be a problem. .NET Core upstream essentially
supports x86_64 only. arm-hfp, aarch64 and x86 are supported to some
extent. Every other platform is pretty much unsupported.

Thanks,
Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
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/message/KEAXTLKC52CL7AX6L6Y6XUBW65GO6HDD/

Fedora 29 compose report: 20180822.n.0 changes

2018-08-22 Thread Fedora Branched Report

OLD: Fedora-29-20180821.n.0
NEW: Fedora-29-20180822.n.0

= SUMMARY =
Added images:7
Dropped images:  2
Added packages:  7
Dropped packages:0
Upgraded packages:   66
Downgraded packages: 0

Size of added packages:  38.07 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.99 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -182.63 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-29-20180822.n.0.x86_64.vagrant-libvirt.box
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-29-20180822.n.0.iso
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-29-20180822.n.0.x86_64.vagrant-virtualbox.box
Image: Robotics live i386
Path: Labs/i386/iso/Fedora-Robotics-Live-i386-29-20180822.n.0.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-29-20180822.n.0.iso
Image: Astronomy_KDE live i386
Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-29-20180822.n.0.iso
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-29-20180822.n.0.iso

= DROPPED IMAGES =
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-29-20180821.n.0.iso
Image: Cinnamon live i386
Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-29-20180821.n.0.iso

= ADDED PACKAGES =
Package: bubblewrap-0.3.0-2.module_2123+73a9ef6f
Summary: Core execution tool for unprivileged containers
RPMs:bubblewrap
Size:271.92 KiB

Package: eog-3.28.3-1.module_2123+73a9ef6f
Summary: Eye of GNOME image viewer
RPMs:eog eog-devel eog-tests
Size:28.86 MiB

Package: exempi-2.4.5-3.module_2123+73a9ef6f
Summary: Library for easy parsing of XMP metadata
RPMs:exempi exempi-devel
Size:3.65 MiB

Package: gnome-desktop3-3.29.90.1-1.module_2123+73a9ef6f
Summary: Shared code among gnome-panel, gnome-session, nautilus, etc
RPMs:gnome-desktop3 gnome-desktop3-devel gnome-desktop3-tests
Size:3.73 MiB

Package: libpeas-1.22.0-9.module_2123+73a9ef6f
Summary: Plug-ins implementation convenience library
RPMs:libpeas libpeas-devel libpeas-gtk libpeas-loader-python3
Size:1.52 MiB

Package: python-pytest-expect-1.1.0-1.fc29
Summary: py.test plugin to store test expectations and mark tests based on them
RPMs:python3-pytest-expect
Size:16.10 KiB

Package: python-u-msgpack-python-2.5.0-1.fc29
Summary: A portable, lightweight MessagePack serializer and deserializer
RPMs:python3-u-msgpack-python
Size:25.73 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  argbash-2.7.0-1.fc29
Old package:  argbash-2.6.1-3.fc29
Summary:  Bash argument parsing code generator
RPMs: argbash
Size: 51.23 KiB
Size change:  2.66 KiB
Changelog:
  * Thu Jul 19 2018 Stephen Gallagher  - 2.7.0-1
  - Update to 2.7.0
  - https://github.com/matejak/argbash/releases/tag/2.7.0


Package:  bouncycastle-1.60-1.fc29
Old package:  bouncycastle-1.59-2.fc29
Summary:  Bouncy Castle Cryptography APIs for Java
RPMs: bouncycastle bouncycastle-javadoc bouncycastle-mail 
bouncycastle-pg bouncycastle-pkix bouncycastle-tls
Size: 9.47 MiB
Size change:  196.70 KiB
Changelog:
  * Tue Aug 21 2018 Mat Booth  - 1.60-1
  - Update to latest upstream release


Package:  cantor-18.04.3-2.fc29
Old package:  cantor-18.04.3-1.fc29
Summary:  KDE Frontend to Mathematical Software
RPMs: cantor cantor-devel cantor-libs python2-cantor python3-cantor
Size: 10.44 MiB
Size change:  1.09 KiB
Changelog:
  * Tue Aug 21 2018 Mukundan Ragavan  - 18.04.3-2
  - rebuild for libqalculate.so.19()


Package:  dconf-0.28.0-3.fc29
Old package:  dconf-0.28.0-2.fc29
Summary:  A configuration system
RPMs: dconf dconf-devel
Size: 757.25 KiB
Size change:  -52.10 KiB
Changelog:
  * Tue Aug 21 2018 Owen Taylor  - 0.28.0-3
  - Add a patch to enable DCONF_USER_CONFIG_DIR environment variable


Package:  dustmite-1-39.20150515git3498068.fc29
Old package:  dustmite-1-38.20150515git3498068.fc29
Summary:  Minimizes D source code for debugging
RPMs: dustmite
Size: 1014.92 KiB
Size change:  249.27 KiB
Changelog:
  * Tue Aug 21 2018 Peter Robinson  
1-39.20150515git3498068
  - Rebuild for aarch64 enablement


Package:  eclipse-1:4.9.0-0.2.fc29
Old package:  eclipse-1:4.8.0-4.fc29
Summary:  An open, extensible IDE
RPMs: eclipse-contributor-tools eclipse-equinox-osgi eclipse-jdt 
eclipse-p2-discovery eclipse-pde eclipse-platform eclipse-swt eclipse-tests
Size: 1.49 GiB
Size change:  -176.78 MiB
Changelog:
  * Sun Aug 19 2018 Mat Booth  - 1:4.9.0-0.1
  - Update to latest I-build
  - Update license

  * Mon Aug 20 2018 Mat Booth  - 1:4.9.0-0.2
  - Fix secondary arch build


Package:  eclipse-ecf-3.14.1-3.fc29
Old

Re: Intent to upgrade Django in f29 to 2.1


On 22.8.2018 13:13, Matthias Runge wrote:

On Wed, Aug 22, 2018 at 11:51:34AM +0200, Miro Hrončok wrote:

On 22.8.2018 10:59, Matthias Runge wrote:

Hello,

sorry for the late notice; Django 2.1 was recently released, and
I intend to update Django in F29 to version 2.1.

Apparently, all depending packages still build, all the details
in https://bugzilla.redhat.com/show_bug.cgi?id=1611025


2 packages don't. Sorry if that was confusing. They only build in f29 (that
is without Django 2.1).


Ah, sorry, I've misread the comment.

Django-avatar: seems to be failing, according to the classifiers, it
doesn't support Django-2.0 either, although commits hint something else.
This year already saw 2 commits to upstream, nothing connected to 2.1.

django-countries: has seen more commits upstream this year.

However, these packages would be broken by the upgrade :(

Thoughts?


Keep the update in rawhide for now, try to get the packages fixed and if 
it cannot be done before beta freeze, don't push the update?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/message/QBIRNC4YBFQFGVCKWN6EDSFSAWOCT5VM/

Orphaning procedure for python-assimulo

2018-08-22 Thread Antonio Trande

Hello everyone.

I'm leaving the maintenance of 'python-assimulo' package; if someone
wishes take care of it, please reply here.

Regards.
-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/VZLRSGRZEVHTDR6J3RIZT6ISZRCYYYVS/

Re: Intent to upgrade Django in f29 to 2.1


On 22.8.2018 13:13, Matthias Runge wrote:

On Wed, Aug 22, 2018 at 11:51:34AM +0200, Miro Hrončok wrote:

On 22.8.2018 10:59, Matthias Runge wrote:

Hello,

sorry for the late notice; Django 2.1 was recently released, and
I intend to update Django in F29 to version 2.1.

Apparently, all depending packages still build, all the details
in https://bugzilla.redhat.com/show_bug.cgi?id=1611025


2 packages don't. Sorry if that was confusing. They only build in f29 (that
is without Django 2.1).


Ah, sorry, I've misread the comment.

Django-avatar: seems to be failing, according to the classifiers, it
doesn't support Django-2.0 either, although commits hint something else.
This year already saw 2 commits to upstream, nothing connected to 2.1.

django-countries: has seen more commits upstream this year.

However, these packages would be broken by the upgrade :(

Thoughts?


Keep the update in rawhide for now, try to get the packages fixed and if 
it cannot be done before beta freeze, don't push the update?


--
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/message/QBIRNC4YBFQFGVCKWN6EDSFSAWOCT5VM/

Re: [modularity] Managing module lifecycles — let's talk!

2018-08-22 Thread Owen Taylor

What are the possibilities for how a stream is maintained? The cases I can
think of:

 * Indefinite - rolling forward with upstream - "master" "stable" etc.
 * Tied to an upstream version and it's EOL -  a "2.1" stream of django
 * [less common] tied to a particular version of Fedora - the "29" stream
of flatpak-runtime

How do your proposed mechanisms handle these cases?

It seems like by trying to automatically determine an EOL, the intent of
module maintainer might not be respected - e.g. you might include a package
with a short EOL intending to rebase to newer versions as necessary.

What if we just had a streams.yaml file checked into the master branch of
git and gave the maintainer the flexibility to set an EOL (with defaults if
no streams.yaml is present, perhaps.) We could still write tools to check
the EOL against that of dependencies and components, but that would just be
used to flag problems.

Owen


On Wed, Aug 22, 2018 at 6:39 AM, Adam Samalik  wrote:

> During the Modularity WG meeting yesterday [1], we've touched the topic of
> module lifecycles. Even though there are some ideas in the air as well as
> some code written, we haven't reached a state in which we would know how
> exactly to deal with it. So I'd like to discuss it here with a wider
> audience, and review it again in the next Modularity WG meeting.
>
> == Introduction: (feel free to skip this if you know what I'm talking
> about)
>
> In concept, modules live more or less independently from the Fedora
> release. So while traditional packages in Fedora are branched for each
> Fedora release (such as f27, f28, etc.), and each branch is maintained for
> the lifetime of its release (~13 months), modular packages and modules
> themselves are branched in any way it makes most sense for the software
> (mostly major version, such as nodejs 6, nodejs 8, nodejs 10, etc.) — we
> call these "stream branches" in dist-git and "streams" when we talk about
> modules. This has two implications, one of which is the topic of this email:
>
> 1) One module stream can be built and maintained for multiple Fedora
> releases — that means it's lifecycle can be longer than just a single
> Fedora release — and that's what this email is about
> 2) One Fedora release can have multiple streams of modules — also cool,
> but not discussed in this email
>
> If you're a visual type, watch this short animation (38 seconds):
> https://www.youtube.com/watch?v=5VQljp1p_ok
>
> == The problem + what we've decided already
>
> Simply put, we need to have a way of indicating how long each module
> stream lives. This should be probably defined at the package level, because
> packages the actual software that is being maintained.
>
> At Flock 2017 we've discussed this topic and reached a following decision:
> Module stream's lifecycles should be somehow aligned with Fedora releases —
> in particular, they should be retired only at the end of a release. That
> way we prevent a situation where different module streams could be retired
> at any point in time, which would be pretty messy. On the other hand,
> introducing new streams at any time should be possible, the same way as we
> add new packages today.
>
> == Approaches
>
> Option 1: The current, yet unfinished approach
>
> We specify an EOL (end of life) date for each stream branch of individual
> packages. This is done when requesting a new stream branch for a package
> [2] by passing "--sl rawhide:2020-12-01" to fedpkg. This value is stored,
> but not yet consumed by anything.
>
> The next step would be having the build system to be smart enough to:
>
> 1) Figure out the module's EOL based on its packages' EOLs.
> 2) Only build the module for the Fedora releases that have their EOL
> before the module stream's EOL.
>
> There is a caveat, however:  Giving dates like this might be hard for the
> maintainer. The upstream project might not have one, etc. In that case the
> maintainer needs to come up with a date — even one closer in the future,
> and increase it gradually (and think about it, and do it for all the
> packages), or one much further in the future which could imply promises the
> maintainer had no intention to make.
>
> Option 2: More dynamic, based on rawhide
>
> Simply put, we wouldn't specify an EOL as a date, but as a Fedora release.
> And if a maintainer indicates that a certain stream branch of a package is
> maintained in rawhide, it would mean it's maintained for all active Fedora
> releases + the next one + potentially forever or until it's retired in
> rawhide.
>
> The build system would then do the same thing as above:
>
> 1) Figure out the module's EOL based on its packages' EOLs.
> 2) Only build the module for the Fedora releases that have their EOL
> before the module stream's EOL.
>
>
> Let's discuss the overall concept, the two approaches above or propose
> your own, or anything else that you think is relevant.
>
> Cheers!
> Adam
>
> [1]

Help needed with FTBFS of package cpl in i686 and Fedora>=29

2018-08-22 Thread Sergio Pascual

Hello, I'm trying to fix a FTBFS bug in cpl, a C library. The package fails
in i686 on Fedora>=29 and compiles in Fedora<=28

https://koji.fedoraproject.org/koji/taskinfo?taskID=29215071

https://kojipkgs.fedoraproject.org//work/tasks/5071/29215071/build.log

I imagine that, after enabling SSE2 in Fedora 29, we are compiling a
different code path
that fails. I don't have any experience with this kind of code.
The error is related with _m_from_int64, that seems undefined? But
_m_from_int64 is defined in one of the *intrin.h headers. I'm don't know
what is happening.


cpl_image_basic.c: In function 'dcompl_mult_sse_fast':
cpl_image_basic.c:245:30: warning: implicit declaration of function
'_m_from_int64'; did you mean '_m_from_int'?
[-Wimplicit-function-declaration]
 #define cpl_m_from_int64 _m_from_int64
  ^
cpl_image_basic.c:260:54: note: in expansion of macro 'cpl_m_from_int64'
   _mm_add_pd(a, _mm_xor_pd(b,
(__m128d)_mm_set_epi64(cpl_m_from_int64(0x0llu), \
  ^~~~
cpl_image_basic.c:4065:12: note: in expansion of macro 'CPL_MM_ADDSUB_PD'
 return CPL_MM_ADDSUB_PD(t1, sb); /* x * y - y * w, z*y + x * w */
^~~~
cpl_image_basic.c:245:30: error: incompatible type for argument 1 of
'_mm_set_epi64'
 #define cpl_m_from_int64 _m_from_int64
  ^
cpl_image_basic.c:260:54: note: in expansion of macro 'cpl_m_from_int64'
   _mm_add_pd(a, _mm_xor_pd(b,
(__m128d)_mm_set_epi64(cpl_m_from_int64(0x0llu), \
  ^~~~
cpl_image_basic.c:4065:12: note: in expansion of macro 'CPL_MM_ADDSUB_PD'
 return CPL_MM_ADDSUB_PD(t1, sb); /* x * y - y * w, z*y + x * w */
^~~~
In file included from
/usr/lib/gcc/i686-redhat-linux/8/include/xmmintrin.h:1252,
 from cpl_image_basic.c:240:
/usr/lib/gcc/i686-redhat-linux/8/include/emmintrin.h:595:22: note: expected
'__m64' {aka '__vector(2) int'} but argument is of type 'int'
 _mm_set_epi64 (__m64 __q1,  __m64 __q0)
~~^~~~

 cpl_image_basic.c:245:30: error: incompatible type for argument 2 of
'_mm_set_epi64'
 #define cpl_m_from_int64 _m_from_int64


Any help would be appreciated, I have never touched code like this.

Best, Sergio
___
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/message/JAHKEG2PUN5IX2KMIJUXQHJN5YBXBL6E/

Re: Orphaning procedure for python-ivi -vxi11 -usbtmc -testify


On 22.8.2018 15:52, Manas Mangaonkar wrote:

Thanks for the link,will do :)


If you are going to take care of those packages, I'd appreciate if you 
remove the python2 bits from them.




On Wed, 22 Aug 2018, 15:15 Antonio Trande, > wrote:


At this point, the packages are orphaned.

Please, follow the 'Claiming Ownership of an Orphaned Package'
guidelines:

https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package

On 22/08/2018 07:05, Manas Mangaonkar wrote:
 > Hey,
 >
 > Please assign them to me,i recently began packaging and looking
for more
 > experience as i enjoy doing it.
 >
 > - Manas
 >
 > On Wed, 22 Aug 2018, 00:19 Antonio Trande, mailto:anto.tra...@gmail.com>
 > >> wrote:
 >
 >     Hello everyone.
 >
 >     I'm orphaning following Python packages on Fedora (and EPEL):
 >
 >     python-ivi
 >     python-vxi11
 >     python-usbtmc
 >     python-testify
 >
 >     I will retire them within 3 weeks if none is interested to
maintain any
 >     or all of them.
 >
 >     Regards.
 >     --
 >     ---
 >     Antonio Trande
 >     Fedora Project
 >     mailto 'sagitter at fedoraproject dot org'
 >     GPG key: 0x5E212EE1D35568BE
 >     GPG key server: https://keys.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/message/UYP3TXTGWD5FUCNQ47SJUJBRMRE5ZLJK/
 >
 >
 >
 > ___
 > 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/message/J7UVBAWU326WVEIUPUQTAOHKMXOCREAY/
 >

-- 
---

Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.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/message/GQUP22T6L5FTUD6HZ6L5KYWNHY34SGJC/



___
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/message/YMP33N5R25LQGXGOFWSVMM5BYK6TSJG6/



--
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/message/5TXC3HWTAPCOGBSZJS5GHUVM4MEDYQ4I/

Re: Orphaning procedure for python-ivi -vxi11 -usbtmc -testify

2018-08-22 Thread Manas Mangaonkar

Thanks for the link,will do :)

- Manas

On Wed, 22 Aug 2018, 15:15 Antonio Trande,  wrote:

> At this point, the packages are orphaned.
>
> Please, follow the 'Claiming Ownership of an Orphaned Package'
> guidelines:
>
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package
>
> On 22/08/2018 07:05, Manas Mangaonkar wrote:
> > Hey,
> >
> > Please assign them to me,i recently began packaging and looking for more
> > experience as i enjoy doing it.
> >
> > - Manas
> >
> > On Wed, 22 Aug 2018, 00:19 Antonio Trande,  > > wrote:
> >
> > Hello everyone.
> >
> > I'm orphaning following Python packages on Fedora (and EPEL):
> >
> > python-ivi
> > python-vxi11
> > python-usbtmc
> > python-testify
> >
> > I will retire them within 3 weeks if none is interested to maintain
> any
> > or all of them.
> >
> > Regards.
> > --
> > ---
> > Antonio Trande
> > Fedora Project
> > mailto 'sagitter at fedoraproject dot org'
> > GPG key: 0x5E212EE1D35568BE
> > GPG key server: https://keys.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/message/UYP3TXTGWD5FUCNQ47SJUJBRMRE5ZLJK/
> >
> >
> >
> > ___
> > 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/message/J7UVBAWU326WVEIUPUQTAOHKMXOCREAY/
> >
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.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/message/GQUP22T6L5FTUD6HZ6L5KYWNHY34SGJC/
>
___
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/message/YMP33N5R25LQGXGOFWSVMM5BYK6TSJG6/

Reminder: Beta freeze and code complete deadline in one week

According to the Fedora 29 schedule[1], the 100% code complete
deadline[2] for Changes is Tuesday, 28 August. The beta freeze[3]
takes effect on this date as well. All Changes should be in "ON_QA"
state by then.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule
[2] 
https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_100.25_code_complete_deadline
[3] https://fedoraproject.org/wiki/Milestone_freezes

-- 
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/message/WWUGJ2WNOXKGLOQM3WXSD6YF74B53G7L/

Re: Release rpkg-1.56 and fedpkg-1.35

2018-08-22 Thread Jun Aruga

> rpkg: https://docs.pagure.org/rpkg/releases/1.56.html
> Greenwave policy could be validated when build a package with build command, 
> or a container with container-build command, if policy file gating.yaml is 
> created in the root directory inside repostiory. If the policy is valid, 
> build will be proceeded, otherwise, packagers have to fix it.

It looks cool new feature of Greenwave [1]. Thanks.
In my impression, we have several CIs, Greenwave, Fedora CI, testing
framework for modularity on Fedora Project.

[1] https://docs.pagure.org/greenwave/policies.html

Jun



On Wed, Aug 22, 2018 at 9:22 AM, Chenxiong Qi  wrote:
> Hi,
>
> New version rpkg-1.56 and fedpkg-1.35 are released.
>
> Release notes:
>
> * rpkg: https://docs.pagure.org/rpkg/releases/1.56.html
> * fedpkg: https://docs.pagure.org/fedpkg/releases/1.35.html
>
> Bodhi updates:
>
> https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.fc28%20fedpkg-1.35-1.fc28
> https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.fc27%20fedpkg-1.35-1.fc27
> https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.el6%20fedpkg-1.35-1.el6
> https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.el7%20fedpkg-1.35-1.el7
>
> Regards,
> Chenxiong Qi
>
> ___
> 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/message/WH7TMHJ565ETG2OSG5VRUO5NOBW3VXYO/



-- 
Jun Aruga jar...@redhat.com
IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno,
Czech Republic
___
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/message/W2I4IIVJOHTH7IGJXHSNI3EUWW6377OD/

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

2018-08-22 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  73  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  41  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d801e05f92   
uwsgi-2.0.17.1-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f21474267b   
condor-8.6.11-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d143ebd7cc   
tomcat-7.0.90-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-785de4dd7a   
lighttpd-1.4.47-2.el6


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

fedpkg-1.35-1.el6
rpkg-1.56-1.el6

Details about builds:



 fedpkg-1.35-1.el6 (FEDORA-EPEL-2018-8d36e5f524)
 Fedora utility for working with dist-git

Update Information:

 rpkg: https://docs.pagure.org/rpkg/releases/1.56.html  fedpkg:
https://docs.pagure.org/fedpkg/releases/1.35.html

ChangeLog:

* Tue Aug 21 2018 Chenxiong Qi  - 1.35-1
- Reserve last bodhi template on error - rhbz#1467897 (cqi)
- New command releases-info - #247 (cqi)
- Fix a test for request-repo command (cqi)
- New option to request a repo without an initial commit - #215 (cqi)
- Add --shell to bash completion for mockbuild (cqi)
- Greenwave conf and support for gating validation (gnaponie)
- Allow to create update directly with CLI options - #93 rhbz#1007157 (cqi)
- Add more tests for utils (cqi)
- Rewrite method to create bodhi update - rhbz#1492480 (cqi)
- Mock fedora.client.OpenIdBaseClient._load_cookies (cqi)
- Do not use configparser.SafeConfigParser in tests (cqi)
- Fix test_retire to use unittest2 in el6 (cqi)
- Submit builds from stream branch (cqi)
- The create new project is not needed for packager (pingou)
- Add py37 testenv (cqi)
- Set PYCURL_SSL_LIBRARY directly for installing pycurl (cqi)
- Fix flake8 errors and typo in tests (cqi)
- Add tests for some commands (cqi)
- Add tests for utils.py (cqi)
- Convert test case for utils.py as normal test case (cqi)
- Add some tests for BugzillaClient (cqi)
- Fix TypeError raised from override create command - #256 (cqi)
- Add missing command and options in bash completion (cqi)

References:

  [ 1 ] Bug #1438685 - Add --shell  to the rhpkg command
https://bugzilla.redhat.com/show_bug.cgi?id=1438685
  [ 2 ] Bug #1583822 - fedpkg shouldn't assemble the rpm in 
~/rpmbuild/BUILDROOT/
https://bugzilla.redhat.com/show_bug.cgi?id=1583822
  [ 3 ] Bug #1492480 - fedpkg update without type has cryptic error message
https://bugzilla.redhat.com/show_bug.cgi?id=1492480
  [ 4 ] Bug #1007157 - Allow bodhi command line options for fedpkg update
https://bugzilla.redhat.com/show_bug.cgi?id=1007157
  [ 5 ] Bug #1467897 - fedpkg update throws my update text on error
https://bugzilla.redhat.com/show_bug.cgi?id=1467897




 rpkg-1.56-1.el6 (FEDORA-EPEL-2018-8d36e5f524)
 Python library for interacting with rpm+git

Update Information:

 rpkg: https://docs.pagure.org/rpkg/releases/1.56.html  fedpkg:
https://docs.pagure.org/fedpkg/releases/1.35.html

ChangeLog:

* Tue Aug 21 2018 Chenxiong Qi  - 1.56-1
- Validate greenwave policy early in Commands.build (cqi)
- Refine error message for failure gating.yaml validation (cqi)
- explain mbs-manager exception handling (nils)
- test for missing mbs-manager with errno set (nils)
- catch errno == ENOENT if mbs-manager is missing (nils)
- add missing method docstring (nils)
- Show full error from MBS (lsedlar)
- Fix tests for greenwave policy validation (cqi)
- Add testenv for building docs (cqi)
- New option --buildrootdir - rhbz#1583822 (cqi)
- Add --shell option to mockbuild - rhbz#1438685 (cqi)
- Validate gating.yaml file for Greenwave gating (gnaponie)
- Update README (cqi)
- Reduce the number of repo creation for tests (cqi)
- Fix flake8 error (cqi)
- Drop rpm-py-installer from requires - #357 (cqi)
- Allow _run_command to capture and return output to stdout or stderr (cqi)
- Claim Python 3.7 in README and package classifiers (cqi)
- Fix a bad test teardown (otaylor)
- Refactor build command (cqi)
- Remove rpmfluff package (cqi)
- Set PYCURL_SSL_LIBRARY directly for installing pycurl (cqi)
- Add py37 testenv (cqi)
* Thu Jul 26 2018 Chenxiong Qi  - 1.55-2
- Remove dependency python-rpmfluff

[Bug 1614708] perldoc warns about binary data depending on TERM variable

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



--- Comment #4 from Fedora Update System  ---
perl-Pod-Perldoc-3.28.01-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/HZ67KUVCOU3NOQYIJT2R3XXHFDCMSLIJ/

[Bug 1612855] perl-HTTP-Tiny-0.076 is available

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



--- Comment #7 from Fedora Update System  ---
perl-HTTP-Tiny-0.076-1.fc28 has been pushed to the Fedora 28 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/ALMK4TFDXM6IQE3KFVIL3AZ66RIVCTL6/

[Bug 1610065] perl-HTTP-Tiny-0.074 is available

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



--- Comment #11 from Fedora Update System  ---
perl-HTTP-Tiny-0.076-1.fc28 has been pushed to the Fedora 28 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/CV4SFJ4CWC72PQER66RYEAHUTO4WEISX/

[Bug 1613225] Upgrade perl-Text-Quoted to 2.10

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Text-Quoted-2.10-1.fc2 |perl-Text-Quoted-2.10-1.fc2
   |7   |7
   ||perl-Text-Quoted-2.10-1.fc2
   ||8



--- Comment #7 from Fedora Update System  ---
perl-Text-Quoted-2.10-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/UZKPXNVOQIFZQUH46CXMLU3HECUAB26H/

Re: Intent to upgrade Django in f29 to 2.1

On Wed, Aug 22, 2018 at 11:51:34AM +0200, Miro Hrončok wrote:
> On 22.8.2018 10:59, Matthias Runge wrote:
> > Hello,
> > 
> > sorry for the late notice; Django 2.1 was recently released, and
> > I intend to update Django in F29 to version 2.1.
> > 
> > Apparently, all depending packages still build, all the details
> > in https://bugzilla.redhat.com/show_bug.cgi?id=1611025
> 
> 2 packages don't. Sorry if that was confusing. They only build in f29 (that
> is without Django 2.1).

Ah, sorry, I've misread the comment.

Django-avatar: seems to be failing, according to the classifiers, it
doesn't support Django-2.0 either, although commits hint something else.
This year already saw 2 commits to upstream, nothing connected to 2.1.

django-countries: has seen more commits upstream this year.

However, these packages would be broken by the upgrade :(

Thoughts?
-- 
Matthias Runge 
___
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/message/MIXAWORFHNZIUQRIWLLG4THLP5V2ZO4D/

Re: Intent to upgrade Django in f29 to 2.1

On Wed, Aug 22, 2018 at 11:51:34AM +0200, Miro Hrončok wrote:
> On 22.8.2018 10:59, Matthias Runge wrote:
> > Hello,
> > 
> > sorry for the late notice; Django 2.1 was recently released, and
> > I intend to update Django in F29 to version 2.1.
> > 
> > Apparently, all depending packages still build, all the details
> > in https://bugzilla.redhat.com/show_bug.cgi?id=1611025
> 
> 2 packages don't. Sorry if that was confusing. They only build in f29 (that
> is without Django 2.1).

Ah, sorry, I've misread the comment.

Django-avatar: seems to be failing, according to the classifiers, it
doesn't support Django-2.0 either, although commits hint something else.
This year already saw 2 commits to upstream, nothing connected to 2.1.

django-countries: has seen more commits upstream this year.

However, these packages would be broken by the upgrade :(

Thoughts?
-- 
Matthias Runge 
___
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/message/MIXAWORFHNZIUQRIWLLG4THLP5V2ZO4D/

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

2018-08-22 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  73  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a   
unrtf-0.21.9-8.el7
  67  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-15b7dc35af   
pass-1.7.2-1.el7
  41  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d2e0971e9b   
uwsgi-2.0.17.1-1.el7
  24  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a   
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
  23  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5346e2123a   
dpkg-1.18.25-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0be0127779   
libgit2-0.26.6-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-33f460bd9c   
moodle-3.1.13-2.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dce803ff0d   
lighttpd-1.4.50-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-69993b3f45   
sleuthkit-4.6.2-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6f182ddbf7   
python34-3.4.9-1.el7


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

adobe-source-code-pro-fonts-2.030.1.050-5.el7
fedpkg-1.35-1.el7
rpkg-1.56-1.el7
yubico-piv-tool-1.6.1-1.el7

Details about builds:



 adobe-source-code-pro-fonts-2.030.1.050-5.el7 (FEDORA-EPEL-2018-20d41c4ad6)
 A set of mono-spaced OpenType fonts designed for coding environments

Update Information:

Align with Fedora releases.

ChangeLog:

* Thu Jul 12 2018 Fedora Release Engineering  - 
2.030.1.050-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Wed Feb  7 2018 Fedora Release Engineering  - 
2.030.1.050-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Jul 26 2017 Fedora Release Engineering  - 
2.030.1.050-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Fri Feb 10 2017 Fedora Release Engineering  - 
2.030.1.050-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Sat Jul 23 2016 Michael Kuhn  - 2.030.1.050-1
- Update to roman fonts 2.030 and italic fonts 1.050
* Wed Feb  3 2016 Fedora Release Engineering  - 
2.010.1.030-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild




 fedpkg-1.35-1.el7 (FEDORA-EPEL-2018-b9c5bded6e)
 Fedora utility for working with dist-git

Update Information:

 rpkg: https://docs.pagure.org/rpkg/releases/1.56.html  fedpkg:
https://docs.pagure.org/fedpkg/releases/1.35.html

ChangeLog:

* Tue Aug 21 2018 Chenxiong Qi  - 1.35-1
- Reserve last bodhi template on error - rhbz#1467897 (cqi)
- New command releases-info - #247 (cqi)
- Fix a test for request-repo command (cqi)
- New option to request a repo without an initial commit - #215 (cqi)
- Add --shell to bash completion for mockbuild (cqi)
- Greenwave conf and support for gating validation (gnaponie)
- Allow to create update directly with CLI options - #93 rhbz#1007157 (cqi)
- Add more tests for utils (cqi)
- Rewrite method to create bodhi update - rhbz#1492480 (cqi)
- Mock fedora.client.OpenIdBaseClient._load_cookies (cqi)
- Do not use configparser.SafeConfigParser in tests (cqi)
- Fix test_retire to use unittest2 in el6 (cqi)
- Submit builds from stream branch (cqi)
- The create new project is not needed for packager (pingou)
- Add py37 testenv (cqi)
- Set PYCURL_SSL_LIBRARY directly for installing pycurl (cqi)
- Fix flake8 errors and typo in tests (cqi)
- Add tests for some commands (cqi)
- Add tests for utils.py (cqi)
- Convert test case for utils.py as normal test case (cqi)
- Add some tests for BugzillaClient (cqi)
- Fix TypeError raised from override create command - #256 (cqi)
- Add missing command and options in bash completion (cqi)

References:

  [ 1 ] Bug #1438685 - Add --shell  to the rhpkg command
https://bugzilla.redhat.com/show_bug.cgi?id=1438685
  [ 2 ] Bug #1583822 - fedpkg shouldn't assemble the rpm in 
~/rpmbuild/BUILDROOT/
https://bugzilla.redhat.com/show_bug.cgi?id=1583822
  [ 3 ] Bug #1492480 - fedpkg update without type has cryptic error message
https://bugzilla.redhat.com/show_bug.cgi?id=1492480
  [ 4 ] Bug #1007157 - Allow bodhi command line options for fedpkg update

[Bug 1610065] perl-HTTP-Tiny-0.074 is available

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



--- Comment #10 from Fedora Update System  ---
perl-HTTP-Tiny-0.076-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/ZPG2H25MWPZJ54WYKOWMDQBA6XBR3NDC/

[Bug 1612855] perl-HTTP-Tiny-0.076 is available

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



--- Comment #6 from Fedora Update System  ---
perl-HTTP-Tiny-0.076-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/QLX4N24KHTMXEMXEHWFQQLHGVICS2PAF/

[Bug 1613225] Upgrade perl-Text-Quoted to 2.10

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Text-Quoted-2.10-1.fc2
   ||7
 Resolution|--- |ERRATA
Last Closed||2018-08-22 06:43:21



--- Comment #6 from Fedora Update System  ---
perl-Text-Quoted-2.10-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/KMCVWFRLSPFR6RVXF6APL6U3TDRVPIYN/

[modularity] Managing module lifecycles — let's talk!

2018-08-22 Thread Adam Samalik

During the Modularity WG meeting yesterday [1], we've touched the topic of
module lifecycles. Even though there are some ideas in the air as well as
some code written, we haven't reached a state in which we would know how
exactly to deal with it. So I'd like to discuss it here with a wider
audience, and review it again in the next Modularity WG meeting.

== Introduction: (feel free to skip this if you know what I'm talking about)

In concept, modules live more or less independently from the Fedora
release. So while traditional packages in Fedora are branched for each
Fedora release (such as f27, f28, etc.), and each branch is maintained for
the lifetime of its release (~13 months), modular packages and modules
themselves are branched in any way it makes most sense for the software
(mostly major version, such as nodejs 6, nodejs 8, nodejs 10, etc.) — we
call these "stream branches" in dist-git and "streams" when we talk about
modules. This has two implications, one of which is the topic of this email:

1) One module stream can be built and maintained for multiple Fedora
releases — that means it's lifecycle can be longer than just a single
Fedora release — and that's what this email is about
2) One Fedora release can have multiple streams of modules — also cool, but
not discussed in this email

If you're a visual type, watch this short animation (38 seconds):
https://www.youtube.com/watch?v=5VQljp1p_ok

== The problem + what we've decided already

Simply put, we need to have a way of indicating how long each module stream
lives. This should be probably defined at the package level, because
packages the actual software that is being maintained.

At Flock 2017 we've discussed this topic and reached a following decision:
Module stream's lifecycles should be somehow aligned with Fedora releases —
in particular, they should be retired only at the end of a release. That
way we prevent a situation where different module streams could be retired
at any point in time, which would be pretty messy. On the other hand,
introducing new streams at any time should be possible, the same way as we
add new packages today.

== Approaches

Option 1: The current, yet unfinished approach

We specify an EOL (end of life) date for each stream branch of individual
packages. This is done when requesting a new stream branch for a package
[2] by passing "--sl rawhide:2020-12-01" to fedpkg. This value is stored,
but not yet consumed by anything.

The next step would be having the build system to be smart enough to:

1) Figure out the module's EOL based on its packages' EOLs.
2) Only build the module for the Fedora releases that have their EOL before
the module stream's EOL.

There is a caveat, however: Giving dates like this might be hard for the
maintainer. The upstream project might not have one, etc. In that case the
maintainer needs to come up with a date — even one closer in the future,
and increase it gradually (and think about it, and do it for all the
packages), or one much further in the future which could imply promises the
maintainer had no intention to make.

Option 2: More dynamic, based on rawhide

Simply put, we wouldn't specify an EOL as a date, but as a Fedora release.
And if a maintainer indicates that a certain stream branch of a package is
maintained in rawhide, it would mean it's maintained for all active Fedora
releases + the next one + potentially forever or until it's retired in
rawhide.

The build system would then do the same thing as above:

1) Figure out the module's EOL based on its packages' EOLs.
2) Only build the module for the Fedora releases that have their EOL before
the module stream's EOL.

Let's discuss the overall concept, the two approaches above or propose your
own, or anything else that you think is relevant.

Cheers!
Adam

[1]
https://meetbot.fedoraproject.org/fedora-meeting-3/2018-08-21/modularity_wg.2018-08-21-14.01.html
[2]
https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/#_repositories_and_stream_branches_existing_packages

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/K4FUOQHQSRAAI3PUUGXAC6CXEN27Y2JH/

Fwd: Soname break for glew

2018-08-22 Thread Nicolas Chauvet

I'm preparing an update for glew to 2.1.0 (with soname bump)
(pushed in rawhide but not built yet).
https://koji.fedoraproject.org/koji/taskinfo?taskID=29087244

Given that the freeze break is next week, I will push the update in
rawhide, then in f29 next.

Here are the dependencies:
FlightGear-Atlas-0.5.0-0.46.cvs20141002.fc29.src.rpm
OpenColorIO-1.1.0-7.fc29.src.rpm
amanith-0.3-39.fc29.src.rpm
avogadro-1.2.0-20.fc29.src.rpm
avogadro2-libs-1.91.0-0.2.20180612gitda6ebb9.fc29.src.rpm
blender-2.79b-6.fc29.src.rpm
camotics-1.1.1-13.fc29.src.rpm
cegui-0.8.7-11.fc29.src.rpm
cegui06-0.6.2-29.fc29.src.rpm
compat-SFML16-1.6-18.fc29.src.rpm
dreamchess-0.3.0-0.3.20180601git.fc29.src.rpm
endless-sky-0.9.8-6.fc29.src.rpm
freeorion-0.4.7.1-11.fc29.src.rpm
gambas3-3.11.4-1.fc29.src.rpm
gimp-normalmap-1.2.3-17.fc28.src.rpm
gource-0.48-1.fc28.src.rpm
hugin-2018.0.0-2.fc28.src.rpm
hyperrogue-10.0-5.d.fc29.src.rpm
k3d-0.8.0.6-16.fc29.src.rpm
kalzium-18.04.3-1.fc29.src.rpm
kicad-5.0.0-2.fc29.src.rpm
libprojectM-2.1.0-8.fc29.src.rpm
linphone-3.6.1-27.fc29.src.rpm
logstalgia-1.1.2-2.fc29.src.rpm
megaglest-3.12.0-7.fc29.src.rpm
mesa-demos-8.3.0-11.fc29.src.rpm
meshlab-2016.12-6.fc29.src.rpm
openclonk-8.1-4.20180321git570ba7a.fc29.src.rpm
opencsg-1.4.2-7.fc29.src.rpm
openmsx-0.14.0-7.fc29.src.rpm
openscad-2015.03.3-17.fc29.src.rpm
paraview-5.5.2-16.fc29.src.rpm
pymol-2.1.0-3.20180321svn4187.fc29.src.rpm
quesoglc-0.7.2-21.fc29.src.rpm
root-6.14.02-1.fc29.src.rpm
rss-glx-0.9.1.p-35.fc29.src.rpm
scorched3d-44-16.fc29.src.rpm
sdljava-0.9.1-41.fc29.src.rpm
slop-7.4-3.fc29.src.rpm
spring-100.0-13.fc28.src.rpm
supertux-0.5.1-12.fc29.src.rpm
supertuxkart-0.9.3-2.fc29.4.src.rpm
toped-0.9.81-18.svn2211.fc28.src.rpm
warzone2100-3.2.3-7.fc29.src.rpm
widelands-0-0.66.build19.fc29.src.rpm
wt-4.0.3-1.fc29.src.rpm
wxmacmolplt-7.7-9.fc29.src.rpm


--
-

Nicolas (kwizart)


-- 
-

Nicolas (kwizart)
___
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/message/HLD22BK5FUPBTTZTT4BDL7RXQZZARER7/

Re: Intent to upgrade Django in f29 to 2.1


On 22.8.2018 10:59, Matthias Runge wrote:

Hello,

sorry for the late notice; Django 2.1 was recently released, and
I intend to update Django in F29 to version 2.1.

Apparently, all depending packages still build, all the details
in https://bugzilla.redhat.com/show_bug.cgi?id=1611025


2 packages don't. Sorry if that was confusing. They only build in f29 
(that is without Django 2.1).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/message/7FK7B5MK4OD4WD2EAYGMOINH5R6LJU44/

Re: Intent to upgrade Django in f29 to 2.1


On 22.8.2018 10:59, Matthias Runge wrote:

Hello,

sorry for the late notice; Django 2.1 was recently released, and
I intend to update Django in F29 to version 2.1.

Apparently, all depending packages still build, all the details
in https://bugzilla.redhat.com/show_bug.cgi?id=1611025


2 packages don't. Sorry if that was confusing. They only build in f29 
(that is without Django 2.1).


--
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/message/7FK7B5MK4OD4WD2EAYGMOINH5R6LJU44/

Intent to upgrade Django in f29 to 2.1

Hello,

sorry for the late notice; Django 2.1 was recently released, and
I intend to update Django in F29 to version 2.1.

Apparently, all depending packages still build, all the details
in https://bugzilla.redhat.com/show_bug.cgi?id=1611025

If I don't hear anything against it until Monday, I'll merge rawhide into
F29.

Matthias
-- 
Matthias Runge 
___
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/message/SRFRSTSGHTBO5IZSFASVYPMBAQWPSPTV/

Intent to upgrade Django in f29 to 2.1

Hello,

sorry for the late notice; Django 2.1 was recently released, and
I intend to update Django in F29 to version 2.1.

Apparently, all depending packages still build, all the details
in https://bugzilla.redhat.com/show_bug.cgi?id=1611025

If I don't hear anything against it until Monday, I'll merge rawhide into
F29.

Matthias
-- 
Matthias Runge 
___
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/message/SRFRSTSGHTBO5IZSFASVYPMBAQWPSPTV/

Re: Orphaning procedure for python-ivi -vxi11 -usbtmc -testify

2018-08-22 Thread Antonio Trande

At this point, the packages are orphaned.

Please, follow the 'Claiming Ownership of an Orphaned Package'
guidelines:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package

On 22/08/2018 07:05, Manas Mangaonkar wrote:
> Hey,
> 
> Please assign them to me,i recently began packaging and looking for more
> experience as i enjoy doing it. 
> 
> - Manas 
> 
> On Wed, 22 Aug 2018, 00:19 Antonio Trande,  > wrote:
> 
> Hello everyone.
> 
> I'm orphaning following Python packages on Fedora (and EPEL):
> 
> python-ivi
> python-vxi11
> python-usbtmc
> python-testify
> 
> I will retire them within 3 weeks if none is interested to maintain any
> or all of them.
> 
> Regards.
> -- 
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.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/message/UYP3TXTGWD5FUCNQ47SJUJBRMRE5ZLJK/
> 
> 
> 
> ___
> 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/message/J7UVBAWU326WVEIUPUQTAOHKMXOCREAY/
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/GQUP22T6L5FTUD6HZ6L5KYWNHY34SGJC/

[Bug 1616198] perl-IO-Socket-SSL-2.058-1.fc29 FTBFS with OpenSSL 1.1.1: t/ core.t hangs

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |NEXTRELEASE
Last Closed||2018-08-22 04:10:38



--- Comment #4 from Petr Pisar  ---
Builds are done. My gut feeling is that IO::Socket::SSL::close() should be
changed to perform full SSL connection shutdown by default. Now it defaults to
plain deallocating SSL data structures and closing TCP directly. That way
TLSv1.3 servers may become unhappy because of unexpected failures in accept().
We will see and if that become a real issue I will amend IO::Socket::SSL.
Please report any issues.

-- 
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/message/NZ66BTHTO75235HRDPCOXKYFUG6QXGVN/

[Bug 1616179] perl-Text-CSV-1.96 is available