[Bug 1466106] New: /bin/re.pl fails to start (missing LexEnv, DDS, ... modules)

[bugzilla]

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

Bug ID: 1466106
   Summary: /bin/re.pl fails to start (missing  LexEnv, DDS, ...
modules)
   Product: Fedora
   Version: 25
 Component: perl-Devel-REPL
  Assignee: ppi...@redhat.com
  Reporter: prais...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com



$ re.pl 
Unable to locate plugin 'LexEnv' at
/usr/share/perl5/vendor_perl/Devel/REPL/Profile/Minimal.pm line 16.

$ re.pl 
Unable to locate plugin 'DDS' at
/usr/share/perl5/vendor_perl/Devel/REPL/Profile/Minimal.pm line 16.

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

Re: Intel i915 firmwares

[Sean V Kelley]

> On Jun 28, 2017, at 4:20 AM, David Airlie  wrote:
> 
> 
>> I ran into this today:
>> https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
>> 
>> DRM firmware is loaded by default. HuC and GuC are not. Things work
>> without them, and things work with them loaded. So what's the pro/con
>> and if there's a pro, why isn't it the kernel default? Seems like if
>> it should be default, either upstream should set them as the default,
>> or the CPU/GPU should ask for it?
> 
> I expect when upstream decided they are stable and useful enough, upstream
> will enable them. I'm not fully sure how useful they are, I think they
> might possibly enable lower power states, but also nasty bugs.
> 
> 
HUC is used for bit rate control when using the low power fixed function AVC 
encoder(vdenc) on supported platforms. (Libva/intel-vapid-driver)


> Dave.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: Fix majority of broken CI cases

[William Brown]

https://pagure.io/389-ds-base/issue/49302

https://pagure.io/389-ds-base/issue/raw/012558ba4eefe04a6cbfb7eb5c742cf1b66f610552b6f05fc2262105bd53bc69-0001-Ticket-49302-fix-dirsrv-importst-due-to-lib389-chang.patch

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 843  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 605  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 187  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
  85  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
  83  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5f9a6163b4   
tnef-1.4.14-1.el7
  82  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4aae1e22f1   
lxc-1.0.10-2.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d9786818e4   
python-nbxmpp-0.5.6-1.el7 gajim-0.16.8-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-30baf73207   
chromium-59.0.3071.104-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-abfcb66c76   
python-djblets-0.9.8-1.el7 ReviewBoard-2.5.13.1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5ab90c7180   
zabbix20-2.0.21-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-eb357ac3b3   
zabbix22-2.2.18-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7c2e699925   
catdoc-0.95-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b6bc17c1   
globus-xio-5.16-1.el7 globus-net-manager-0.17-1.el7 
globus-gass-cache-program-6.7-1.el7 globus-gass-copy-9.27-1.el7 
globus-gssapi-gsi-12.16-1.el7 globus-gram-job-manager-14.36-1.el7 
globus-gridftp-server-12.2-1.el7 globus-io-11.9-1.el7 
globus-xio-gsi-driver-3.11-1.el7 globus-xio-pipe-driver-3.10-1.el7 
globus-xio-udt-driver-1.27-1.el7 myproxy-6.1.28-1.el7 
globus-ftp-client-8.35-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bcfa38e123   
drupal7-7.56-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1ee32a5ffa   
libtomcrypt-1.17-25.el7 libtommath-0.42.0-5.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2b04537603   
phpMyAdmin-4.4.15.10-2.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2ba20eeb97   
php-horde-Horde-Image-2.5.1-1.el7


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

Zim-0.67-0.rc2.1.el7
awscli-1.11.109-2.el7
dmlite-0.8.7-1.el7
perl-MetaCPAN-API-Tiny-1.131730-4.el7
php-gecko-packages-gecko-php-unit-2.1-1.el7
python-botocore-1.5.72-1.el7
python-pocketlint-0.15-1.el7
python-rpmfluff-0.5.3-1.el7

Details about builds:



 Zim-0.67-0.rc2.1.el7 (FEDORA-EPEL-2017-835f8c3158)
 Desktop wiki & notekeeper

Update Information:

This is fixing an issue that makes notebooks corrupt with the update of Zim 0.66
  Update to Zim 0.66

References:

  [ 1 ] Bug #1457991 - Zim 0.66 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1457991




 awscli-1.11.109-2.el7 (FEDORA-EPEL-2017-f0df4cfbde)
 Universal Command Line Environment for AWS

Update Information:

update




 dmlite-0.8.7-1.el7 (FEDORA-EPEL-2017-f3a3fbb167)
 Lcgdm grid data management and storage framework

Update Information:

* new upstream release

References:

  [ 1 ] Bug #1449040 - Broken postun scriptlet
https://bugzilla.redhat.com/show_bug.cgi?id=1449040




 perl-MetaCPAN-API-Tiny-1.131730-4.el7 (FEDORA-EPEL-2017-079ac682df)
 A Tiny API client for MetaCPAN

Update Information:

Switch to v1 MetaCPAN API as the v0 API has been closed down.
https://rt.cpan.org/Public/Bug/Display.html?id=122004




 php-gecko-packages-gecko-php-unit-2.1-1.el7 (FEDORA-EPEL-2017-9e3ff1b2a7)
 Additional PHPUnit tests

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 721  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 715  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 605  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 577  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 187  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
  83  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c0d33ae70f   
tnef-1.4.14-1.el6
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-23f4cb5d02   
lxc-1.0.10-2.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6489eec271   
golang-1.7.6-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-fc2d88e3d3   
zabbix20-2.0.21-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-94b8514427   
zabbix22-2.2.18-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d99d50d751   
catdoc-0.95-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b1d8b4aed9   
globus-xio-5.16-1.el6 globus-net-manager-0.17-1.el6 
globus-gass-cache-program-6.7-1.el6 globus-gass-copy-9.27-1.el6 
globus-gssapi-gsi-12.16-1.el6 globus-gram-job-manager-14.36-1.el6 
globus-gridftp-server-12.2-1.el6 globus-io-11.9-1.el6 
globus-xio-gsi-driver-3.11-1.el6 globus-xio-pipe-driver-3.10-1.el6 
globus-xio-udt-driver-1.27-1.el6 myproxy-6.1.28-1.el6 
globus-ftp-client-8.35-2.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f7d349f9b4   
drupal7-7.56-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1490b54059   
libtomcrypt-1.17-25.el6 libtommath-0.42.0-5.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2e08fc8a0d   
phpMyAdmin-4.0.10.20-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8ba2ea7136   
php-horde-Horde-Image-2.5.1-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d29b462920   
libmtp11-1.1.13-1.el6


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

dmlite-0.8.7-1.el6

Details about builds:



 dmlite-0.8.7-1.el6 (FEDORA-EPEL-2017-2a97f85209)
 Lcgdm grid data management and storage framework

Update Information:

* new upstream release

References:

  [ 1 ] Bug #1449040 - Broken postun scriptlet
https://bugzilla.redhat.com/show_bug.cgi?id=1449040

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Adam Williamson]

On Thu, 2017-06-29 at 12:11 +1000, Nick Coghlan wrote:
> On 29 June 2017 at 11:39, Adam Williamson  wrote:
> > On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:
> > > 2) Using `python-` instead of `python2-` in the dependencies for the
> > > Python 2 binary RPM [2].
> > 
> > I'm not sure this list is terribly useful, because of the above. There
> > are thousands of packages that do this, because the 'python2-' provide
> > is not available on some older Fedora release, or on EPEL (and the
> > package is maintained for EPEL as well as Fedora). Sprinkling "if (some
> > release number condition) then Requires: python2-foo else Requires:
> > python-foo" all over your spec is a giant PITA and I for one am not
> > very interested in doing it.
> > 
> > IMHO, if there is going to be some kind of requirement that all Python
> > requires be explicitly versioned, there needs to be a co-ordinated
> > effort to make sure the versioned Provides are available across at
> > least EL6, EL7, and all supported Fedora releases *first*.
> 
> This was the key concern I raised in response to the initial email,
> and our conclusion at the time was:
> 
> 1. This case does need to be addressed
> 2. Adding an opaque dependency on buildroot configuration settings
> wouldn't be a particularly nice way to handle it, since it forces
> every package to switch concurrently, rather than each maintainer
> getting to decide when to move from the Python 2 stack to the Python 3
> stack for themselves (and that unilateral shift is already going to
> happen for unqualified dependency declarations when the virtual
> %python_provides macro moves from the Python 2 stack to the Python 3
> stack)
> 3. Ideally, the recommended approach would work for arbitrary RHEL &
> CentOS based buildroots, not just those with the EPEL RPM macros
> available
> 
> The most straightforward solution we came up with was for affected
> packages to define their own "%py_prefix" macro that selects the stack
> they want to use based on the Python version:
> 
> ```
> # The block below would become the conventional
> # "Python stack compatibility" dance for
> # EL6, EL7, and Fedora
> # Each package can decide for itself which version of
> # Fedora had a sufficiently complete Py3 stack for
> # them to be able to switch over
> 
> # Current EL releases & older Fedora use "python-*"
> %if 0%{?el6} || 0%{?el7} || 0%{?fedora} < 25
> %define py_prefix python
> %if 0%{?el6} || 0%{?el7}
> BuildRequires: python-devel
> %else
> BuildRequires: python2-devel
> %endif
> %else
> # Newer Fedora releases use "pythonX-*"
> # A Py2-only project would use "python2" here
> %define py_prefix python3
> BuildRequires: python3-devel
> %endif
> 
> 
> # Dependency declarations use stack selected above
> BuildRequires: %{py_prefix}-builddep1
> BuildRequires: %{py_prefix}-builddep2
> Requires: %{py_prefix}-runtimedep1
> Requires: %{py_prefix}-runtimedep2
> ```

Erf, well, that seems kinda icky but manageable. Is it really better
than just coming up with some kind of script to at least add the
appropriate "Provides: python2-foo" to all packages (or at least a
large subset of the most commonly-used packages) in EL6/EL7/F24,
though? I mean, that doesn't seem beyond the bounds of possibility, to
just find everything that provides 'python-foo' and make it also
provide 'python2-foo'...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Nick Coghlan]

On 29 June 2017 at 11:39, Adam Williamson  wrote:
> On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:
>> 2) Using `python-` instead of `python2-` in the dependencies for the
>> Python 2 binary RPM [2].
>
> I'm not sure this list is terribly useful, because of the above. There
> are thousands of packages that do this, because the 'python2-' provide
> is not available on some older Fedora release, or on EPEL (and the
> package is maintained for EPEL as well as Fedora). Sprinkling "if (some
> release number condition) then Requires: python2-foo else Requires:
> python-foo" all over your spec is a giant PITA and I for one am not
> very interested in doing it.
>
> IMHO, if there is going to be some kind of requirement that all Python
> requires be explicitly versioned, there needs to be a co-ordinated
> effort to make sure the versioned Provides are available across at
> least EL6, EL7, and all supported Fedora releases *first*.

This was the key concern I raised in response to the initial email,
and our conclusion at the time was:

1. This case does need to be addressed
2. Adding an opaque dependency on buildroot configuration settings
wouldn't be a particularly nice way to handle it, since it forces
every package to switch concurrently, rather than each maintainer
getting to decide when to move from the Python 2 stack to the Python 3
stack for themselves (and that unilateral shift is already going to
happen for unqualified dependency declarations when the virtual
%python_provides macro moves from the Python 2 stack to the Python 3
stack)
3. Ideally, the recommended approach would work for arbitrary RHEL &
CentOS based buildroots, not just those with the EPEL RPM macros
available

The most straightforward solution we came up with was for affected
packages to define their own "%py_prefix" macro that selects the stack
they want to use based on the Python version:

```
# The block below would become the conventional
# "Python stack compatibility" dance for
# EL6, EL7, and Fedora
# Each package can decide for itself which version of
# Fedora had a sufficiently complete Py3 stack for
# them to be able to switch over

# Current EL releases & older Fedora use "python-*"
%if 0%{?el6} || 0%{?el7} || 0%{?fedora} < 25
%define py_prefix python
%if 0%{?el6} || 0%{?el7}
BuildRequires: python-devel
%else
BuildRequires: python2-devel
%endif
%else
# Newer Fedora releases use "pythonX-*"
# A Py2-only project would use "python2" here
%define py_prefix python3
BuildRequires: python3-devel
%endif


# Dependency declarations use stack selected above
BuildRequires: %{py_prefix}-builddep1
BuildRequires: %{py_prefix}-builddep2
Requires: %{py_prefix}-runtimedep1
Requires: %{py_prefix}-runtimedep2
```

For dual stack libraries, the appropriate prefixes to define would be
separate ones for each stack (%py2_prefix and %py3_prefix), and either
leave the latter undefined for systems with no native Py3 stack, or
else set it to rely on EPEL, IUS, or a suitable software collection.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Nick Coghlan]

On 29 June 2017 at 11:39, Adam Williamson  wrote:
> On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:
>> 2) Using `python-` instead of `python2-` in the dependencies for the
>> Python 2 binary RPM [2].
>
> I'm not sure this list is terribly useful, because of the above. There
> are thousands of packages that do this, because the 'python2-' provide
> is not available on some older Fedora release, or on EPEL (and the
> package is maintained for EPEL as well as Fedora). Sprinkling "if (some
> release number condition) then Requires: python2-foo else Requires:
> python-foo" all over your spec is a giant PITA and I for one am not
> very interested in doing it.
>
> IMHO, if there is going to be some kind of requirement that all Python
> requires be explicitly versioned, there needs to be a co-ordinated
> effort to make sure the versioned Provides are available across at
> least EL6, EL7, and all supported Fedora releases *first*.

This was the key concern I raised in response to the initial email,
and our conclusion at the time was:

1. This case does need to be addressed
2. Adding an opaque dependency on buildroot configuration settings
wouldn't be a particularly nice way to handle it, since it forces
every package to switch concurrently, rather than each maintainer
getting to decide when to move from the Python 2 stack to the Python 3
stack for themselves (and that unilateral shift is already going to
happen for unqualified dependency declarations when the virtual
%python_provides macro moves from the Python 2 stack to the Python 3
stack)
3. Ideally, the recommended approach would work for arbitrary RHEL &
CentOS based buildroots, not just those with the EPEL RPM macros
available

The most straightforward solution we came up with was for affected
packages to define their own "%py_prefix" macro that selects the stack
they want to use based on the Python version:

```
# The block below would become the conventional
# "Python stack compatibility" dance for
# EL6, EL7, and Fedora
# Each package can decide for itself which version of
# Fedora had a sufficiently complete Py3 stack for
# them to be able to switch over

# Current EL releases & older Fedora use "python-*"
%if 0%{?el6} || 0%{?el7} || 0%{?fedora} < 25
%define py_prefix python
%if 0%{?el6} || 0%{?el7}
BuildRequires: python-devel
%else
BuildRequires: python2-devel
%endif
%else
# Newer Fedora releases use "pythonX-*"
# A Py2-only project would use "python2" here
%define py_prefix python3
BuildRequires: python3-devel
%endif


# Dependency declarations use stack selected above
BuildRequires: %{py_prefix}-builddep1
BuildRequires: %{py_prefix}-builddep2
Requires: %{py_prefix}-runtimedep1
Requires: %{py_prefix}-runtimedep2
```

For dual stack libraries, the appropriate prefixes to define would be
separate ones for each stack (%py2_prefix and %py3_prefix), and either
leave the latter undefined for systems with no native Py3 stack, or
else set it to rely on EPEL, IUS, or a suitable software collection.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

[Adam Williamson]

On Wed, 2017-06-28 at 13:27 -0400, Matthew Miller wrote:
> On Tue, Jun 27, 2017 at 03:10:16PM -0700, Adam Williamson wrote:
> > > As Fedora stands today, of course, "the Fedora Server repo" means "all
> > > the stuff Fedora packages at all".
> > 
> > Um. Does it? I am not entirely sure if this is what was meant in
> > context, but there *is* a "Fedora Server repo" which does *not* contain
> > "all the stuff Fedora packages at all" - for instance, the repos you
> > can find under:
> 
> I know, but as you've heard me whining about before, that's a weird
> artifact of the build process that leaks out onto the mirrors. Once you
> have a Fedora Server system up and running you're pointed at
> Everything.

Well, yes, but *in context*, the text was specifying the extent of the
package set it covered. It seems, to me, at least as likely that the
intent of the text was "the Change will cover all the packages in the
Server install tree" as "the Change will cover all the packages in the
'fedora' repository".

I don't think it's necessary or appropriate to debate the nature or
desirability of the Server install tree repos at this point, as the
actual practical *point* under discussion here is what the text
actually means in defining the scope of the Change.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Adam Williamson]

On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:
> 2) Using `python-` instead of `python2-` in the dependencies for the 
> Python 2 binary RPM [2].

I'm not sure this list is terribly useful, because of the above. There
are thousands of packages that do this, because the 'python2-' provide
is not available on some older Fedora release, or on EPEL (and the
package is maintained for EPEL as well as Fedora). Sprinkling "if (some
release number condition) then Requires: python2-foo else Requires:
python-foo" all over your spec is a giant PITA and I for one am not
very interested in doing it.

IMHO, if there is going to be some kind of requirement that all Python
requires be explicitly versioned, there needs to be a co-ordinated
effort to make sure the versioned Provides are available across at
least EL6, EL7, and all supported Fedora releases *first*.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

[Adam Williamson]

On Wed, 2017-06-28 at 07:54 -0400, Josh Boyer wrote:
> On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
>  wrote:
> > On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:
> > > 
> > > I cannot argue with the criteria as you have set forth.  However, I
> > > never said we should block the release.  I said it should work on the
> > > architectures it does today.  That is more than x86_64.  We *know* we
> > > have significant interest from multiple parties around Server on other
> > > architectures.  This comes from both the project sponsor and from
> > > parties representing those architectures.  They are even participating
> > > members in the Server WG.  So while you may not hold a Fedora release
> > > for it, I do not think it is out of line to come into a Modular Server
> > > release with the intention of it actually working across multiple CPU
> > > architectures.
> > 
> > Well, there is of course potentially a gap between "the intention of it
> > actually working" and...actually working :)
> 
> One we bridge well today, given that it works on things other than x86_64.

Well, sure. I don't really know what the point of this is any more? I
don't think anyone disagrees about anything. The only point I really
wanted to raise is that we aren't at present actually committed to
ensuring Server works on arches other than x86_64 at the level of the
release process, and this might potentially mean that we wouldn't
commit to ensuring modular Server is fully functional on other arches
as part of the F27 release. I don't think there's any question that we
want the whole modularity process to fundamentally work on all arches,
though.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1466083] New: perl-WWW-Mechanize-1.85 is available

[bugzilla]

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

Bug ID: 1466083
   Summary: perl-WWW-Mechanize-1.85 is available
   Product: Fedora
   Version: rawhide
 Component: perl-WWW-Mechanize
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org



Latest upstream release: 1.85
Current version/release in rawhide: 1.84-3.fc27
URL: http://search.cpan.org/dist/WWW-Mechanize/

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

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

[Bug 1466082] perl-SNMP-Info-3.36 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-SNMP-Info-3.36-1.el7.src.rpm for rawhide failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=20236827

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

[Bug 1466082] perl-SNMP-Info-3.36 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1292724
  --> https://bugzilla.redhat.com/attachment.cgi?id=1292724=edit
[patch] Update to 3.36 (#1466082)

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

[Bug 1466082] New: perl-SNMP-Info-3.36 is available

[bugzilla]

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

Bug ID: 1466082
   Summary: perl-SNMP-Info-3.36 is available
   Product: Fedora
   Version: rawhide
 Component: perl-SNMP-Info
  Keywords: FutureFeature, Triaged
  Assignee: w...@gouldfamily.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org,
w...@gouldfamily.org



Latest upstream release: 3.36
Current version/release in rawhide: 3.34-3.fc27
URL: http://search.cpan.org/dist/SNMP-Info/

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

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

[Bug 1466079] New: perl-Module-ScanDeps-1.24 is available

[bugzilla]

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

Bug ID: 1466079
   Summary: perl-Module-ScanDeps-1.24 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Module-ScanDeps
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org



Latest upstream release: 1.24
Current version/release in rawhide: 1.23-4.fc27
URL: http://search.cpan.org/dist/Module-ScanDeps/

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

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

Re: Intel i915 firmwares

[David Airlie]

No not the same upstream.

I'll look into the hdmi audio situation when I get back from holidays.


- Original Message -
> From: "Tomasz Torcz" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, 28 June, 2017 8:52:03 PM
> Subject: Re: Intel i915 firmwares
> 
> On Wed, Jun 28, 2017 at 05:20:13AM -0400, David Airlie wrote:
> > 
> > > I ran into this today:
> > > https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
> > > 
> > > DRM firmware is loaded by default. HuC and GuC are not. Things work
> > > without them, and things work with them loaded. So what's the pro/con
> > > and if there's a pro, why isn't it the kernel default? Seems like if
> > > it should be default, either upstream should set them as the default,
> > > or the CPU/GPU should ask for it?
> > 
> > I expect when upstream decided they are stable and useful enough, upstream
> > will enable them. I'm not fully sure how useful they are, I think they
> > might possibly enable lower power states, but also nasty bugs.
> 
>   The same upstream which did not release stable version of Xorg Intel driver
> for past three years? ;-)
>   According to the link, the firmwares are needed for HDMI audio, which is
> quite critical functionality.  HDMI audio for older chipsets did not
> require binary blobs, so this is kind of regression.
> 
> --
> Tomasz Torcz   "Never underestimate the bandwidth of a station
> xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: Ticket 49303 - Add option to disable TLS client-initiated renegotiation

[Howard Johnson]

https://pagure.io/389-ds-base/issue/49303

https://pagure.io/389-ds-base/issue/raw/7cd5258e54a8bce2f8fa44668e174256bd1cb23fbbf1ede0a3f82157165221e5-0001-Ticket-49303-Add-option-to-disable-TLS-client-initia.patch

--
HJ
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1448632] perl-Params-Validate-1.29 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Params-Validate-1.29-1 |perl-Params-Validate-1.29-1
   |.fc26   |.fc26
   ||perl-Params-Validate-1.29-1
   ||.fc25



--- Comment #14 from Fedora Update System  ---
perl-Params-Validate-1.29-1.fc25 has been pushed to the Fedora 25 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

[Modularity] A proposal for stream naming

[Matthew Miller]

Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.

An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26). For
modules which correspond primarily to a single piece of software (and
associated stuff), it makes sense for the stream to match the major
version of the software: module nodejs might have streams for 8 and 10,
and httpd might have streams for 2.4 and 2.6.

In fact, let's make that a guideline. I believe the existing
https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_stream_and_version
doesn't have any rules, so let's make one. Specifically:

* Modules which correspond primarily to a single application or
  versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
  use a stream label corresponding to the major version of that software
  (e.g. 2.4 or 8)

* Such modules MAY additionally have a "latest" stream, which would be
  "rolling release" of the latest stable version (as opposed to master,
  which corresponds to rawhide and may be unstable).


So far, easy, I think. But what about modules like mine which are
collections of stuff? We could give them an arbitrary version and
increment that. Or, since this module will to follow the same 13-month
lifecycle of a base Fedora release, and make big changes in new streams
on the same cadence, it is tempting to use "f26", "f27" and so on. I
think, though, we want to avoid this, because it introduces a
conceptual overload that will become confusing and limiting.

On the other hand, I want a label that tells people what to expect.
Langdon suggested that expected EOL might be a good way to do this. So,
I propose a convention that modules which do not correspond to single
specific versioned software all follow this convention:

Each such "collection" module MUST have one or both of the following:

  * A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)

  * One or more streams corresponding to "end of life no earlier than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense if we get
to my dream of mixing and matching with CentOS modules)

Additionally and for all of our sanity, I suggest:

  * Valid module end-of-life dates are always either June or December,
corresponding to the Fedora schedule of early May / late October
base releases. So, f1806 or f1812, but not f1810 or f1901.

I know there is some work on stream-to-stream upgrades in modularity;
that work could take advantage of this convention.

So, we'd have:

  httpd 2.4
  httpd 2.6
  nodejs 8
  nodejs 10
  sysadmin-tools latest
  sysadmin-tools f1812
  sysadmin-tools f1906

Does this make sense? Do you have improvements or entirely better
ideas?

I have an alternate idea too: "collection" type modules would
use arbitrary integer versions starting with 1 and increase only if the
content undergoes a major switch. ALL module streams would contain EOL
information after the version number separated by a ":". This EOL info
would be a date as above, or the string "latest", _or_ the string
"stable", indicating that no abi-breaking changes are expected ever and
that we basically have no known EOL.

With this alternate proposal, we'd have:

  httpd 2.4:stable
  httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...)
  nodejs 8:f1912  (because that's upstream eol)
  nodejs 9:f1806  (if someone wants to do the work for a non-lts release)
  nodejs 10:f2106 (or maybe e2012)
  sysadmin-tools 1:latest
  sysadmin-tools 1:f1812
  sysadmin-tools 1:f1906


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Alexander Ploumistos]

On Wed, Jun 28, 2017 at 10:22 PM, Rémi Verschelde  wrote:
> How are you using those links to download the tarball? As far as I
> know if you download through a browser, it will always rename the
> tarball to %{name}-%{commit0}, but if you download with wget or curl
> [0], you should get the tarball name you chose. Note however that the
> folder name within the tarball will always be %{name}-%{commit0}, so
> the interest of naming the tarball itself differently is limited.
>
> [0] e.g.: wget 
> https://github.com/godotengine/godot/archive/9e54e1f/godot-9e54e1f.tar.gz

OK, I am an idiot. I had completely forgotten about that, so yes,
while I was trying to figure which URL to feed to wget, I was using a
browser…

Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Rémi Verschelde]

2017-06-28 20:54 GMT+02:00 Alexander Ploumistos :
>
> Hello and sorry for reviving an old thread, but it was relevant.
>
> Has github removed the capability to name the tarball whatever I
> choose, or could I be doing something wrong?
>
> I have tried downloading tarballs from 4 unrelated repositories using:
> https://github.com/OWNER/%{name}/archive/%{commit0}.tar.gz#/%{name}-%{shortcommit0}.tar.gz
> https://github.com/OWNER/%{name}/archive/%{commit0}/%{name}-%{shortcommit0}.tar.gz
> https://github.com/OWNER/%{name}/archive/%{shortcommit0}/%{name}-%{shortcommit0}.tar.gz
>
> and even:
> https://github.com/OWNER/%{name}/archive/%{commit0}/foo.tar.gz
>
> but I always end up with a %{name}-%{commit0}.tar.gz tarball.

How are you using those links to download the tarball? As far as I
know if you download through a browser, it will always rename the
tarball to %{name}-%{commit0}, but if you download with wget or curl
[0], you should get the tarball name you chose. Note however that the
folder name within the tarball will always be %{name}-%{commit0}, so
the interest of naming the tarball itself differently is limited.

[0] e.g.: wget 
https://github.com/godotengine/godot/archive/9e54e1f/godot-9e54e1f.tar.gz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Alexander Ploumistos]

On Sun, Apr 23, 2017 at 8:23 PM, Christopher  wrote:
> You can set the name of the file via the GitHub API when you download it.
>
> For jQuery (packaged as js-jquery), I use:
> https://github.com/jquery/jquery/archive/%{version}/jquery-%{version}.tar.gz
>
> This will work for any GitHub project which tags released versions:
> https://github.com///archive//.tar.gz
>
> For yours:
> https://github.com/maitra/thaali/archive/master/.tar.gz
>
> But, you shouldn't use "master". You should be more specific about which
> commit you are using, for reproducibility:
> https://github.com/maitra/thaali/archive/7452ae99fe01e7cea6b70881c486775cd1b32186/.tar.gz

Hello and sorry for reviving an old thread, but it was relevant.

Has github removed the capability to name the tarball whatever I
choose, or could I be doing something wrong?

I have tried downloading tarballs from 4 unrelated repositories using:
https://github.com/OWNER/%{name}/archive/%{commit0}.tar.gz#/%{name}-%{shortcommit0}.tar.gz
https://github.com/OWNER/%{name}/archive/%{commit0}/%{name}-%{shortcommit0}.tar.gz
https://github.com/OWNER/%{name}/archive/%{shortcommit0}/%{name}-%{shortcommit0}.tar.gz

and even:
https://github.com/OWNER/%{name}/archive/%{commit0}/foo.tar.gz

but I always end up with a %{name}-%{commit0}.tar.gz tarball.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: R 3.4 update

[Steve Grubb]

On Tuesday, June 27, 2017 4:09:54 PM EDT Steve Grubb wrote:
> On Tuesday, June 27, 2017 3:47:42 PM EDT Adam Williamson wrote:
> > On Sun, 2017-06-25 at 17:08 +0100, José Abílio Matos wrote:
> > > On Sunday, 25 June 2017 16.38.00 WEST Steve Grubb wrote:
> > >
> > > > For example, when I run RStudio, I get:
> > > > 
> > > > R graphics engine version 12 is not supported by this version of
> > > > RStudio. The Plots tab will be disabled until a newer version of
> > > > RStudio is installed.
> > > 
> > > You need to update Rstudio to a newer version. That fixes this issue.
> > > 
> > > > Also:
> > > > 
> > > > Warning: Error in library: there is no package called ‘shinyjs’
> > > > Stack trace (innermost first):
> > > > 41: library
> > > >  1: shiny::runApp
> > > > Error : there is no package called ‘shinyjs’
> > > > 
> > > > So, basically, anyone updating to the new R is dead in the water. It
> > > > really needs to be rolled back to 3.3.3 in F24 & F25. Which leads to
> > > > another issue...where is R in the bugzilla database? I can't find it.
> > > 
> > > The only packages that needed to be rebuild are those that rebuild
> > > packages that register C or Fortran functions:
> > 
> > By policy, the Rstudio update and updates for all those packages should
> > have been included with the update to R itself:
> > 
> > https://fedoraproject.org/wiki/Updates_Policy#Updating_inter-dependent_pac
> > kages
> 
> There really is no way to do this. We don't ship RStudio because its so hard
> to package. I've tried creating a spec file and putting all the pieces
> where it belongs but it doesn't work unless its installed to /usr/local
> which is against Fedora policies. The best I could come up with is to
> create a blog to tell everyone how to build it for themselves.

For anyone following along...since this completely stopped work on my 
projects, I took the time to upgrade to a newer version of Rstudio which works 
with R 3.4. A link to the srpm and some basic instructions can be found here:

http://security-plus-data-science.blogspot.com/2017/06/updated-rstudio-srpm-available.html

-Steve


> There just simply needs to be a rule of no update to a major release during
> a shipped Fedora OS. R 3.3 -> 3.3.1 is fine as that's bug fixes. R 3.3.3
> -> 3.4 has potential to wreck things on already shipped OS.
> 
> > "When one updated package requires another (or more than one other),
> > the packages should be submitted together as a single update. For
> > instance, if package A depends on packages B and C, and you want to
> > update to a new version of package A which requires new versions of B
> > and C, you must submit a single update containing the updated versions
> > of all three packages. It is a bad idea to submit three separate
> > updates, because if the update for package A is pushed stable before
> > the updates for packages B and C, it will cause dependency problems."
> > 
> > Also, it may be worth considering whether updating R to 3.4 is in line
> > with these parts of the policy:
> > 
> > "Releases of the Fedora distribution are like releases of the
> > individual packages that compose it. A major version number reflects a
> > more-or-less stable set of features and functionality. As a result, we
> > should avoid major updates of packages within a stable release. Updates
> > should aim to fix bugs, and not introduce features, particularly when
> > those features would materially affect the user or developer
> > experience. The update rate for any given release should drop off over
> > time, approaching zero near release end-of-life; since updates are
> > primarily bugfixes, fewer and fewer should be needed over time."
> 
> 
> It sounds like this ^^^ fits best.
> 
> 
> > "Package maintainers MUST:
> > 
> > 
> > Avoid Major version updates, ABI breakage or API changes if at all
> > 
> > possible.
> > 
> > Avoid changing the user experience if at all possible.
> > Avoid updates that are trivial or don't affect any Fedora users."
> > 
> > 
> > It would be great if the relevant maintainers could take these points
> > into consideration for future updates. Thanks!
> 
> 
> I'm trying to consider what to do to get a working RStudio again. I suppose
> I 
 can find the packages in the build system and do it manually. But it
> pulled in a little over 20 dependency packages.
> 
> Also, what about the missing bz entry? I'd file a bug but I can't find an
> "R" 
 component to file a bug against. Try it.
> 
> Thanks,
> -Steve
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

[Matthew Miller]

On Tue, Jun 27, 2017 at 03:10:16PM -0700, Adam Williamson wrote:
> > As Fedora stands today, of course, "the Fedora Server repo" means "all
> > the stuff Fedora packages at all".
> Um. Does it? I am not entirely sure if this is what was meant in
> context, but there *is* a "Fedora Server repo" which does *not* contain
> "all the stuff Fedora packages at all" - for instance, the repos you
> can find under:

I know, but as you've heard me whining about before, that's a weird
artifact of the build process that leaks out onto the mirrors. Once you
have a Fedora Server system up and running you're pointed at
Everything. The "Server" package tree is just a red herring and
confusing to users (while wasting at _least_ processing time while
mirroring, if not space and network traffic where hardlinking isn't
available).

If we wanted to change that the other way around and make it a real
thing, I'm not *necessarily* opposed, but it would definitely be a huge
change in user experience.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

[Matthew Miller]

On Tue, Jun 27, 2017 at 01:00:33PM -0700, Adam Williamson wrote:
> Has there yet been any consideration given to *schedule* changes? One
> thing this mail makes abundantly clear is that a lot of work is going
> to be involved in even a minimally viable '1.0' implementation of the
> Modularity concept. Are we confident that this work can be carried out
> to a reasonable standard within a typical Fedora release cycle, and if
> not, are we considering changing the Fedora 27 release schedule?


I'm not confident, but I know there a lot of people in the Factory 2.0,
Rel-Eng, Modularity, and Server WG teams working on it and planning to
make the deadlines.

If we hold to the standard schedule framework, F28 will be May 2018. If
we were to adjust the F27 schedule... December and January aren't great
for releases, so we might look at going to February, but if we do that,
May's not far off anyway. Modularity team (and everyone involved), does
that three months in either direction make a big difference?

Personally, I really like the predictable schedule for planning
reasons*, and I'd rather see a solid contingency plan which allows us to
_really_ back out if it's not 100% ready by Beta (September 5). If that
happens, we can decide to try again for F28 the next May and hopefully
be really solid. Or, if that doesn't seem like it's going to work out,
retool with another approach.


* and, candidly, with the Fedora-Red Hat liason part of my job-hat on,
so does Red Hat, and so do a lot of our other stakeholders like
upstream projects who count on Fedora releases to get their stuff to
users.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170628.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Atomic qcow2 x86_64
Workstation live i386
Cloud_base raw-xz x86_64
Server boot i386
Atomic raw-xz x86_64
Kde live i386

Failed openQA tests: 82/126 (x86_64), 17/18 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170627.n.0):

ID: 114290  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/114290

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

ID: 114180  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/114180
ID: 114181  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/114181
ID: 114182  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/114182
ID: 114183  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/114183
ID: 114191  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/114191
ID: 114192  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/114192
ID: 114201  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/114201
ID: 114202  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/114202
ID: 114203  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/114203
ID: 114204  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/114204
ID: 114205  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/114205
ID: 114206  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/114206
ID: 114207  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/114207
ID: 114216  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/114216
ID: 114218  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/114218
ID: 114219  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/114219
ID: 114220  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/114220
ID: 114221  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/114221
ID: 114222  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/114222
ID: 114223  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/114223
ID: 114224  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/114224
ID: 114235  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/114235
ID: 114237  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/114237
ID: 114238  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/114238
ID: 114239  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/114239
ID: 114241  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/114241
ID: 114242  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/114242
ID: 114243  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/114243
ID: 114244  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/114244
ID: 114245  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/114245
ID: 114246  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/114246
ID: 114247  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/114247
ID: 114248  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/114248
ID: 114249  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/114249
ID: 114250  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/114250
ID: 114251  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/114251
ID: 114252  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/114252
ID: 114253  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/114253
ID: 114254  Test: x86_64 universal 

[Bug 1465991] New: Python3 support

[bugzilla]

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

Bug ID: 1465991
   Summary: Python3 support
   Product: Fedora
   Version: rawhide
 Component: perl-Inline-Python
  Keywords: FutureFeature
  Assignee: j.k.nil...@usit.uio.no
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: j.k.nil...@usit.uio.no,
perl-devel@lists.fedoraproject.org



perl-Inline-Python-0.54-1.fc27 is built against Python 2. It would be great to
build it for Python3. Upstream supports Python3.

The issue is that Makefile.PL has some checks that does work in Fedora.

First one must to override the python executable with INLINE_PYTHON_EXECUTABLE
environment variable.

Second it fails because it cannot find Python3 library:

$ INLINE_PYTHON_EXECUTABLE=/usr/bin/python3 perl Makefile.PL
Using /usr/bin/python3

This python's configuration files are messed up. You'll have have to
answer the questions yourself. Here is what Python said:

   Extra Libs:  -lpthread -ldl  -lutil
   Python Library: 
/usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu/libpython3.6m.a
   Include Path:/usr/include/python3.6m

1. LIBS option. I need to know what extra libraries, if any,
   are required by this build of python. I recommend this:
   -lpthread -ldl  -lutil

The /usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu/libpython3.6m.a file does
not exist. Fedora has /usr/lib64/libpython3.6m.so. It's possible that the check
is bogus because it should check for a shared library.

Commenting out (-f join '/', $ref->{libpath}, $ref->{libpython}) test in
Makefile.PL allows to build against Python 3 and all tests pass.

In case of Python 2, it checks for /usr/lib64/python2.7/config/libpython2.7.so
which is a symlink to /usr/lib64/libpython2.7.so.
In case of Python 3, there is no such symlink.

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

Re: floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Gwyn Ciesla]

On Wed, Jun 28, 2017 at 10:33 AM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> On Wed, 2017-06-28 at 11:03 +0200, Björn Persson wrote:
> > t...@fedoraproject.org wrote:
> > > floppy-support bruno  162
> weeks ago
> >
> > So are floppies now definitely a thing of the past according to Fedora?
>
> If you want them not to be...you can take over the package. We are all
> Fedora. ;) It contains exactly one text file, so maintaining it is
> presumably not the toughest job in the world.
>
> (I saw a pack of floppies for sale in a dollar store the other day,
> made me do a double take...)
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>

I have a bunch of them still.  Don't ask. I'll take floppy-support if no on
else wants it.

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Chris Adams]

Once upon a time, Adam Williamson  said:
> (I saw a pack of floppies for sale in a dollar store the other day,
> made me do a double take...)

I still own the ufiformat package in Fedora (for formatting disks in USB
floppy drives).  I haven't actually used it in quite a while, but I did
run across my USB floppy drive recently...

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Adam Williamson]

On Wed, 2017-06-28 at 11:03 +0200, Björn Persson wrote:
> t...@fedoraproject.org wrote:
> > floppy-support bruno  162 weeks ago 
> 
> So are floppies now definitely a thing of the past according to Fedora?

If you want them not to be...you can take over the package. We are all
Fedora. ;) It contains exactly one text file, so maintaining it is
presumably not the toughest job in the world.

(I saw a pack of floppies for sale in a dollar store the other day,
made me do a double take...)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: Decouple system java setting from java command setting

[Michael Šimáček]

On 2017-06-16 18:44, Dennis Gilmore wrote:

I would like to see some details on how this is going to be
implemented.

It all seem very vague and handwavy


I've just updated the proposal [1] to be more concrete and detailed. Let 
me know if there are still unclear points.


[1] 
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting


Michael



El jue, 08-06-2017 a las 15:55 +0200, Jan Kurik escribió:

= Proposed Self Contained Change: Decouple system java setting from
java command setting =
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_f
rom_java_command_setting

Change owner(s):
* Michael Simacek 
* Mikolaj Izdebski 

Alternatives can be used to specify which Java installation should be
the default for the system. Currently, changing the default java
command causes not only a change to the /usr/bin/java symlink, but
also affects the which runtime is used for system installed Java
applications. We propose introduction of separate setting for
system-wide java applications.


== Detailed Description ==
Fedora allows parallel installation of multiple Java runtime
environments and it uses alternatives mechanism to allow the user to
switch between them. JDK packages provide a set of alternatives
symlinks for it's executables. The java symlink is used to determine
the java command (/usr/bin/java), but also determines which runtime
environment is used to run system-wide Java applications installed
from RPMs, such as maven or eclipse. While in theory different Java
runtime environments are drop-in replacements for each other, in
practice some of the applications may stop working properly. Users
usually install alternative JDKs in order to run their own
applications and don't expect that changing the java command will
have
effect on the system applications. By introducing a separate setting
for system-wide java, we would avoid this problem. We propose
specifying default Java runtime for RPM-managed applications in
/etc/java/java.conf (this is already possible, but not currently
used). Administrators would still be able to override the system
default if they need to.


== Scope ==
* Proposal owners:
Adjust javapackages-tools to provide default Java setting in
/etc/java/java.conf

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/6831

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

perl-Prima-1.52-1.fc27 license change

[Petr Pisar]

perl-Prima-1.52-1.fc27 changed license from 
BSD and MIT and TCL and ImageMagick and LGPLv2+
to
BSD and MIT and TCL and ImageMagick and LGPLv2+ and AGPLv3+.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1465888] perl-Prima-1.52 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Prima-1.52-1.fc27
 Resolution|--- |RAWHIDE
Last Closed||2017-06-28 11:03:16



--- Comment #1 from Petr Pisar  ---
Some fixes but new features and updated build script. Moreover a license
changed. For rawhide only.

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

Broken dependencies: perl-SDL

[buildsys]

perl-SDL has broken dependencies in the rawhide tree:
On x86_64:
perl-SDL-2.546-7.fc26.x86_64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.x86_64 requires perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-SDL-2.546-7.fc26.armv7hl requires libperl.so.5.24
perl-SDL-2.546-7.fc26.armv7hl requires perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-SDL-2.546-7.fc26.ppc64le requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.ppc64le requires perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-SDL-2.546-7.fc26.aarch64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.aarch64 requires perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-SDL-2.546-7.fc26.ppc64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.ppc64 requires perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-SDL-2.546-7.fc26.i686 requires libperl.so.5.24
perl-SDL-2.546-7.fc26.i686 requires perl(:MODULE_COMPAT_5.24.1)
On x86_64:
perl-Module-Build-SDL-2.546-7.fc26.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Module-Build-SDL-2.546-7.fc26.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Module-Build-SDL-2.546-7.fc26.ppc64le requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Module-Build-SDL-2.546-7.fc26.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Module-Build-SDL-2.546-7.fc26.ppc64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Module-Build-SDL-2.546-7.fc26.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Gtk3-WebKit

[buildsys]

perl-Gtk3-WebKit has broken dependencies in the rawhide tree:
On x86_64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-OpenOffice-UNO

[buildsys]

perl-OpenOffice-UNO has broken dependencies in the rawhide tree:
On x86_64:
perl-OpenOffice-UNO-0.07-21.fc26.x86_64 requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-OpenOffice-UNO-0.07-21.fc26.armv7hl requires libperl.so.5.24
perl-OpenOffice-UNO-0.07-21.fc26.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-OpenOffice-UNO-0.07-21.fc26.ppc64le requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.ppc64le requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-OpenOffice-UNO-0.07-21.fc26.aarch64 requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-OpenOffice-UNO-0.07-21.fc26.ppc64 requires libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.ppc64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-OpenOffice-UNO-0.07-21.fc26.i686 requires libperl.so.5.24
perl-OpenOffice-UNO-0.07-21.fc26.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Catalyst-Controller-HTML-FormFu

[buildsys]

perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide 
tree:
On x86_64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-PDL-Graphics-PLplot

[buildsys]

perl-PDL-Graphics-PLplot has broken dependencies in the rawhide tree:
On aarch64:
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
libperl.so.5.24()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
libplplot.so.13()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On x86_64:
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
libperl.so.5.24()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
libplplot.so.13()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires libperl.so.5.24
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires libplplot.so.13
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires libperl.so.5.24
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires libplplot.so.13
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Algorithm-CurveFit

[buildsys]

perl-Algorithm-CurveFit has broken dependencies in the rawhide tree:
On x86_64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-HTML-FormFu-MultiForm

[buildsys]

perl-HTML-FormFu-MultiForm has broken dependencies in the rawhide tree:
On x86_64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'approveacls' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed jplesnik's 'approveacls' permission on rpms/perl-Mail-Box-IMAP4 
(f26) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed ppisar's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 
(f26) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 
(f26) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 
(f26) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed perl-sig's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (f26) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed ppisar's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed ppisar's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 
(f26) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed jplesnik's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 
(f26) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed jplesnik's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (f26) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 (f26) to 'Approved'

[notifications]

limb changed jplesnik's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 
(f26) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb created the branch 'f26' for the package 'rpms/perl-Mail-Box-IMAP4'

[notifications]

limb created the branch 'f26' for the package 'rpms/perl-Mail-Box-IMAP4'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed perl-sig's 'commit' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed ppisar's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed ppisar's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed ppisar's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'approveacls' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed jplesnik's 'approveacls' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed jplesnik's 'watchcommits' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed jplesnik's 'watchbugzilla' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'commit' permission on rpms/perl-Mail-Box-IMAP4 (master) to 'Approved'

[notifications]

limb changed jplesnik's 'commit' permission on rpms/perl-Mail-Box-IMAP4 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb added a new package 'rpms/perl-Mail-Box-IMAP4' (master)

[notifications]

limb added a new package 'rpms/perl-Mail-Box-IMAP4' (master)
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Mail-Box-IMAP4/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Prima (master). "1.52 bump"

[notifications]

From 4644dbe5a4a6b4be5245de51ca97ce7f3076302d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 28 Jun 2017 16:09:25 +0200
Subject: 1.52 bump

---
 .gitignore  |  1 +
 perl-Prima.spec | 17 ++---
 sources |  2 +-
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index 9deec39..c669695 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,3 +11,4 @@
 /Prima-1.49.tar.gz
 /Prima-1.50.tar.gz
 /Prima-1.51.tar.gz
+/Prima-1.52.tar.gz
diff --git a/perl-Prima.spec b/perl-Prima.spec
index 3841aec..b13f8c0 100644
--- a/perl-Prima.spec
+++ b/perl-Prima.spec
@@ -2,12 +2,14 @@
 %{bcond_without perl_Prima_enables_x11_test}
 # Use GTK2 file dialogs and fonts
 %{bcond_without perl_Prima_enables_gtk2}
+# Support colorful cursor via Xcursor
+%{bcond_without perl_Prima_enables_xcursor}
 # Support FreeType fonts via xft
 %{bcond_without perl_Prima_enables_xft}
 
 Name:   perl-Prima
-Version:1.51
-Release:2%{?dist}
+Version:1.52
+Release:1%{?dist}
 Summary:Perl graphic toolkit
 # img/codec_jpeg.c: EXIF parser is based on io-jpeg.c from gdk-pixbuf
 #   (LGPLv2+)
@@ -21,7 +23,8 @@ Summary:Perl graphic toolkit
 # img/codec_X11.c:  MIT
 # pod/Prima/Widget/place.pod:   TCL
 # src/Drawable.c:   TCL
-License:BSD and MIT and TCL and ImageMagick and LGPLv2+
+# examples/tiger.eps:   AGPLv3+   (bundled from GhostScript? CPAN RT#122271)
+License:BSD and MIT and TCL and ImageMagick and LGPLv2+ and AGPLv3+
 URL:http://search.cpan.org/dist/Prima/
 Source0:
http://www.cpan.org/authors/id/K/KA/KARASIK/Prima-%{version}.tar.gz
 BuildRequires:  findutils
@@ -59,6 +62,9 @@ BuildRequires:  pkgconfig(libpng)
 BuildRequires:  pkgconfig(libtiff-4)
 BuildRequires:  pkgconfig(x11)
 BuildRequires:  pkgconfig(xcomposite)
+%if %{with perl_Prima_enables_xcursor}
+BuildRequires:  pkgconfig(xcursor)
+%endif
 BuildRequires:  pkgconfig(xext)
 %if %{with perl_Prima_enables_xft}
 BuildRequires:  pkgconfig(xft)
@@ -168,6 +174,11 @@ find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -delete
 %{_mandir}/man3/Prima::Test.*
 
 %changelog
+* Wed Jun 28 2017 Petr Pisar  - 1.52-1
+- 1.52 bump
+- License changed to "BSD and MIT and TCL and ImageMagick and LGPLv2+ and
+  AGPLv3+"
+
 * Sun Jun 04 2017 Jitka Plesnikova  - 1.51-2
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index 9b8fa66..17ba012 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Prima-1.51.tar.gz) = 
d5a3c2355e7890e6354418f0868ea2a0daa901d816d08073a6d6a7897dbf407be5720df3dc7089dec1e94e19e48a9149326fd3e31fd24e7463a56ee75ba129e1
+SHA512 (Prima-1.52.tar.gz) = 
09dae9e6bbd9a0807554653ef26aed74f2e2de112b31a62a12a5c4a8d5648ecb89a9a153cb843919d5946b04a0beea17d2beca29e98bf4eee2c016a39f244f52
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Prima.git/commit/?h=master=4644dbe5a4a6b4be5245de51ca97ce7f3076302d
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar uploaded Prima-1.52.tar.gz for perl-Prima

[notifications]

09dae9e6bbd9a0807554653ef26aed74f2e2de112b31a62a12a5c4a8d5648ecb89a9a153cb843919d5946b04a0beea17d2beca29e98bf4eee2c016a39f244f52
  Prima-1.52.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Prima/Prima-1.52.tar.gz/sha512/09dae9e6bbd9a0807554653ef26aed74f2e2de112b31a62a12a5c4a8d5648ecb89a9a153cb843919d5946b04a0beea17d2beca29e98bf4eee2c016a39f244f52/Prima-1.52.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Iryna Shcherbina]

Here are lists of packages that don't conform to the current Python 
package naming policy, and their maintainers:


* Maintainers by Package [4]
* Packages by Maintainer [5]

The bad naming is blocking work to switch to Python 3. For more context, 
see [0].


If you are on the list, please check if your packages violate the policy by:

1) Using `python-` instead of `python2-` in the binary RPM name, or 
missing a `python2-` prefix altogether [1].
In case it is, rename the binary RPMs to use `python2-` prefix. Detailed 
steps on how to do this are documented in [3]. (Note that only the 
Python 2 *subpackage* needs renaming; Fedora's "Package Renaming 
Process" doesn't apply here.)


2) Using `python-` instead of `python2-` in the dependencies for the 
Python 2 binary RPM [2].
Check Requires and BuildRequires of the package, and correct those which 
use `python-` prefixed names instead of `python2-`.


Note: the list is generated, so if you see a package that should not be 
on the list, please let me know.


[0] https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
[1] 
https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Python2_binary_package_naming

[2] https://fedoraproject.org/wiki/Packaging:Python#Dependencies
[3] 
https://python-rpm-porting.readthedocs.io/en/latest/naming-scheme.html#what-needs-to-be-changed


[4] Maintainers by Package
2ping - cicku, fale
ATpy - sergiopr
BEDTools - verdurin
CheMPS2 - talcite
LogService - hguemar
NFStest - steved
NLopt - besser82
OpenColorIO - hobbes1069
OpenIPMI - branto, jridky, pknirsch
OpenImageIO - hobbes1069
ProDy - sagitter
PyGreSQL - praiskup
PyMunin - mrunge
PyPAM - msuchy, tmraz
PyQt4 - rdieter, than
PyQuante - jussilehtola
PyRTF - jamatos
PySBIG - mmahut
PyXB - marcusk
PyYAML - jeckersb
Pyrex - marcusk
PythonCard - mmahut
R2spec - pingou
Spawning - kevin
VMDKstream - clalance, imcleod
WALinuxAgent - cottsay
abiword - herrold, uwog
abrt - abrt-team, jfilak, mhabrnal
adapt - pbrobinson
afflib - kwizart
ahkab - sophiekovalevsky
ambari - coolsvap, moceap, pmackinn
ansible - kevin
antlr - gil, mjakubicek
apiextractor - jreznik, rdieter, than
apt - athimm, moceap
aqsis - kwizart
arandr - humaton, mzatko
arm-none-eabi-gdb - mzatko
asymptote - spot
atomic-reactor - bkabrda, maxamillion, ttomecek, twaugh
audit - sgrubb
automake - praiskup
autotest-framework - cleber, dzickus, mkrizek
autowrap - sagitter
avahi - lennart
aws - landgraf, rombobeorn
b43-tools - linville, peter
bacula2 - limb
beakerlib - afri, sopos
beecrypt - robert
belier - louizatakk
bibus - alexlan, ankursinha
bitfrost - cjb, dsd, pbrobinson
bitten - timn
blosc - tnorth, zbyszek
blueproximity - jsteffan
bmpanel2 - mmoeller
boost - denisarnaud, jwakely, pmachata
brial - pcpa
brltty - limb
bro - fab, jtaylor, mildew
bugzilla - eseyman, itamarjp, lbazan
bzr - hno, vvitek
bzr-fastimport - dcallagh
capstone - drago01
carbonate - piotrp
cashe - james
castxml - ellert
catfish - mtasaka
ceph - branto, kkeithle, ktdreyer, siddharths
certmaster - alikins, ssalevan
chameleon - jortel
cjdns - sdgathman
clang - airlied, jvcelak, tstellar
claws-mail - awjb
clearsilver - limb
cloud-utils - juergh, larsks
cloudtoserver - kushal
clufter - jpokorny
clusterPy - volter
cmusphinx3 - jjames
comedilib - mmahut
comix - mtasaka
condor - bcotton, matt
congruity - adamwill
cracklib - tmraz
createrepo_c - tmlcoch
criu - adrian, avagin
crossfire - limb
crudini - apevec, jruzicka, pbrady
cryptominisat4 - jjames
cryptsetup - agk, mbroz
csmock - kdudka
csound - pbrobinson
cups - jpopelka, twaugh, zdohnal
cups-filters - jpopelka, twaugh, zdohnal
cwiid - bogado
cycle - limb
cyphesis - bruno, mpreisle
darkclient - kushal
davix - aalvarez, adev
dbus-python - besser82, rdieter
denyhosts - tibbs
dex-autostart - thofmann
distcc - limb
dmlite - aalvarez, adev, rocha
dnf-plugins-core - ignatenkobrain, jsilhan
dnsperf - pwouters
docco - jamielinux, patches
dogtail - cmeadors, jreznik, vhumpa
dot2tex - radford
dpdk - linville, nhorman
dracut-modules-olpc - cjb, dsd, pbrobinson
dreampie - cicku, williamjmorenor
driconf - kevin
drobo-utils - grover, imntreal
dwgrep - mjw, pmachata
dynafed - andreamanzi
ecryptfs-utils - mhlavink, sandeen
edk2 - bonzini, crobinso
emacs-pymacs - sochotni
eog - kalev
epson-inkjet-printer-escpr - jussilehtola
epydoc - athmane, thias
espresso - junghans, tomspur
etckeeper - thm
fabric - athmane
farstream02 - bpepple, uraeus
fastd - heffer
fedfs-utils - iankent, jlayton, mrchuck, steved
fedora-motd - rtnpro
fedrepos - mdbooth
fedwatch - sochotni
fetchmail - vcrhonek
file - jkaluza, kdudka
firewalld - twoerner
firmware-tools - mebrown, praveenp
fityk - nonamedotc, wojdyr
flexiport - rmattes
freeradius - jdennis, nkondras
fts-rest - aalvarez, simonm
func - alikins, robert, ssalevan
fuse-python - peter
fusionforge - beuc
future - sagitter
gadget - erikos
galternatives - deji, jcapik
gamin - pbrobinson
gammaray - dvratil
ganglia - georgiou, ggillies, noodles, terjeros
garmin-sync - 

[Bug 1450709] perl-Test-Smoke-1.71 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Test-Smoke-1.71-1.fc27
 Resolution|--- |RAWHIDE
Last Closed||2017-06-28 10:21:59



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

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Iryna Shcherbina]

Here are lists of packages that don't conform to the current Python 
package naming policy, and their maintainers:


* Maintainers by Package [4]
* Packages by Maintainer [5]

The bad naming is blocking work to switch to Python 3. For more context, 
see [0].


If you are on the list, please check if your packages violate the policy by:

1) Using `python-` instead of `python2-` in the binary RPM name, or 
missing a `python2-` prefix altogether [1].
In case it is, rename the binary RPMs to use `python2-` prefix. Detailed 
steps on how to do this are documented in [3]. (Note that only the 
Python 2 *subpackage* needs renaming; Fedora's "Package Renaming 
Process" doesn't apply here.)


2) Using `python-` instead of `python2-` in the dependencies for the 
Python 2 binary RPM [2].
Check Requires and BuildRequires of the package, and correct those which 
use `python-` prefixed names instead of `python2-`.


Note: the list is generated, so if you see a package that should not be 
on the list, please let me know.


[0] https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
[1] 
https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Python2_binary_package_naming

[2] https://fedoraproject.org/wiki/Packaging:Python#Dependencies
[3] 
https://python-rpm-porting.readthedocs.io/en/latest/naming-scheme.html#what-needs-to-be-changed


[4] Maintainers by Package
2ping - cicku, fale
ATpy - sergiopr
BEDTools - verdurin
CheMPS2 - talcite
LogService - hguemar
NFStest - steved
NLopt - besser82
OpenColorIO - hobbes1069
OpenIPMI - branto, jridky, pknirsch
OpenImageIO - hobbes1069
ProDy - sagitter
PyGreSQL - praiskup
PyMunin - mrunge
PyPAM - msuchy, tmraz
PyQt4 - rdieter, than
PyQuante - jussilehtola
PyRTF - jamatos
PySBIG - mmahut
PyXB - marcusk
PyYAML - jeckersb
Pyrex - marcusk
PythonCard - mmahut
R2spec - pingou
Spawning - kevin
VMDKstream - clalance, imcleod
WALinuxAgent - cottsay
abiword - herrold, uwog
abrt - abrt-team, jfilak, mhabrnal
adapt - pbrobinson
afflib - kwizart
ahkab - sophiekovalevsky
ambari - coolsvap, moceap, pmackinn
ansible - kevin
antlr - gil, mjakubicek
apiextractor - jreznik, rdieter, than
apt - athimm, moceap
aqsis - kwizart
arandr - humaton, mzatko
arm-none-eabi-gdb - mzatko
asymptote - spot
atomic-reactor - bkabrda, maxamillion, ttomecek, twaugh
audit - sgrubb
automake - praiskup
autotest-framework - cleber, dzickus, mkrizek
autowrap - sagitter
avahi - lennart
aws - landgraf, rombobeorn
b43-tools - linville, peter
bacula2 - limb
beakerlib - afri, sopos
beecrypt - robert
belier - louizatakk
bibus - alexlan, ankursinha
bitfrost - cjb, dsd, pbrobinson
bitten - timn
blosc - tnorth, zbyszek
blueproximity - jsteffan
bmpanel2 - mmoeller
boost - denisarnaud, jwakely, pmachata
brial - pcpa
brltty - limb
bro - fab, jtaylor, mildew
bugzilla - eseyman, itamarjp, lbazan
bzr - hno, vvitek
bzr-fastimport - dcallagh
capstone - drago01
carbonate - piotrp
cashe - james
castxml - ellert
catfish - mtasaka
ceph - branto, kkeithle, ktdreyer, siddharths
certmaster - alikins, ssalevan
chameleon - jortel
cjdns - sdgathman
clang - airlied, jvcelak, tstellar
claws-mail - awjb
clearsilver - limb
cloud-utils - juergh, larsks
cloudtoserver - kushal
clufter - jpokorny
clusterPy - volter
cmusphinx3 - jjames
comedilib - mmahut
comix - mtasaka
condor - bcotton, matt
congruity - adamwill
cracklib - tmraz
createrepo_c - tmlcoch
criu - adrian, avagin
crossfire - limb
crudini - apevec, jruzicka, pbrady
cryptominisat4 - jjames
cryptsetup - agk, mbroz
csmock - kdudka
csound - pbrobinson
cups - jpopelka, twaugh, zdohnal
cups-filters - jpopelka, twaugh, zdohnal
cwiid - bogado
cycle - limb
cyphesis - bruno, mpreisle
darkclient - kushal
davix - aalvarez, adev
dbus-python - besser82, rdieter
denyhosts - tibbs
dex-autostart - thofmann
distcc - limb
dmlite - aalvarez, adev, rocha
dnf-plugins-core - ignatenkobrain, jsilhan
dnsperf - pwouters
docco - jamielinux, patches
dogtail - cmeadors, jreznik, vhumpa
dot2tex - radford
dpdk - linville, nhorman
dracut-modules-olpc - cjb, dsd, pbrobinson
dreampie - cicku, williamjmorenor
driconf - kevin
drobo-utils - grover, imntreal
dwgrep - mjw, pmachata
dynafed - andreamanzi
ecryptfs-utils - mhlavink, sandeen
edk2 - bonzini, crobinso
emacs-pymacs - sochotni
eog - kalev
epson-inkjet-printer-escpr - jussilehtola
epydoc - athmane, thias
espresso - junghans, tomspur
etckeeper - thm
fabric - athmane
farstream02 - bpepple, uraeus
fastd - heffer
fedfs-utils - iankent, jlayton, mrchuck, steved
fedora-motd - rtnpro
fedrepos - mdbooth
fedwatch - sochotni
fetchmail - vcrhonek
file - jkaluza, kdudka
firewalld - twoerner
firmware-tools - mebrown, praveenp
fityk - nonamedotc, wojdyr
flexiport - rmattes
freeradius - jdennis, nkondras
fts-rest - aalvarez, simonm
func - alikins, robert, ssalevan
fuse-python - peter
fusionforge - beuc
future - sagitter
gadget - erikos
galternatives - deji, jcapik
gamin - pbrobinson
gammaray - dvratil
ganglia - georgiou, ggillies, noodles, terjeros
garmin-sync - 

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

[Josh Boyer]

On Wed, Jun 28, 2017 at 10:06 AM, Stephen John Smoogen  wrote:
> On 28 June 2017 at 07:54, Josh Boyer  wrote:
>> On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
>>  wrote:
>>> On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:

 I cannot argue with the criteria as you have set forth.  However, I
 never said we should block the release.  I said it should work on the
 architectures it does today.  That is more than x86_64.  We *know* we
 have significant interest from multiple parties around Server on other
 architectures.  This comes from both the project sponsor and from
 parties representing those architectures.  They are even participating
 members in the Server WG.  So while you may not hold a Fedora release
 for it, I do not think it is out of line to come into a Modular Server
 release with the intention of it actually working across multiple CPU
 architectures.
>>>
>>> Well, there is of course potentially a gap between "the intention of it
>>> actually working" and...actually working :)
>>
>> One we bridge well today, given that it works on things other than x86_64.
>
> But does it work by design or accident on those. And I don't mean that
> snarkily but in a "we actually haven't looked at making it work and
> focused on other parts versus looking at it at all."

We have people that test it on all the architectures it is produced,
and report and try to resolve bugs found.

> In the end, we need to make this a concrete proposal. What resources
> are we going to get to make sure that it can work on whatever other
> architectures are being added to the list? Will these people be

Nothing is being added.  We already produce Server on these architectures.

> dedicated to make this work and what are all the groups outside of
> either modularity or server group which might be needed to make it
> work? And what architectures are we talking about as must haves?

Everyone seems to be misunderstanding what I'm saying.  I am not
saying we need to make all architectures release blocking.  I am
saying that we should aim to preserve status quo today, where Server
is produced across all architectures and issues preventing it from
being produced are clearly reported.  That way people that are
interested in these architectures can work towards keeping the Server
Edition a viable option, irregardless of whether it is release
blocking or not.

Now, I would *love* to make Server release blocking on x86_64,
ppc64le, and aarch64.  However, that's a discussion that needs to
happen with the Server WG in terms of what criteria are required, etc.
I believe that may have started for aarch64 in some way, which is
great.  But that's orthogonal from modularity.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Test-Smoke (master). "1.71 bump"

[notifications]

From de07dc86e845633dd725af4a1f0932bbd021ea51 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 5 Jun 2017 14:51:38 +0200
Subject: Perl 5.26 rebuild

---
 perl-Test-Smoke.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Test-Smoke.spec b/perl-Test-Smoke.spec
index 78ef76a..d2c6a12 100644
--- a/perl-Test-Smoke.spec
+++ b/perl-Test-Smoke.spec
@@ -1,6 +1,6 @@
 Name:   perl-Test-Smoke
 Version:1.70
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Perl core test smoke suite
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -126,6 +126,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jun 05 2017 Jitka Plesnikova  - 1.70-6
+- Perl 5.26 rebuild
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
1.70-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Test-Smoke.git/commit/?h=master=adc4591d1fa61be47d1a4cba4c1685ff2a109d5e
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Test-Smoke (master). "1.71 bump"

[notifications]

From 93b01ab889171e4c219d54f9840a2fcc9e88a34f Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 28 Jun 2017 16:14:07 +0200
Subject: 1.71 bump

---
 .gitignore|  1 +
 Test-Smoke-1.70-Fix-cpuinfo-for-aarch64.patch | 17 -
 perl-Test-Smoke.spec  | 13 +++--
 sources   |  2 +-
 4 files changed, 9 insertions(+), 24 deletions(-)
 delete mode 100644 Test-Smoke-1.70-Fix-cpuinfo-for-aarch64.patch

diff --git a/.gitignore b/.gitignore
index e064442..ccab8e6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Test-Smoke-1.43.tar.gz
 /Test-Smoke-1.59.tar.gz
 /Test-Smoke-1.6.tar.gz
 /Test-Smoke-1.70.tar.gz
+/Test-Smoke-1.71.tar.gz
diff --git a/Test-Smoke-1.70-Fix-cpuinfo-for-aarch64.patch 
b/Test-Smoke-1.70-Fix-cpuinfo-for-aarch64.patch
deleted file mode 100644
index 2ed161c..000
--- a/Test-Smoke-1.70-Fix-cpuinfo-for-aarch64.patch
+++ /dev/null
@@ -1,17 +0,0 @@
-diff -up Test-Smoke-1.70/lib/Test/Smoke/SysInfo/Linux.pm.orig 
Test-Smoke-1.70/lib/Test/Smoke/SysInfo/Linux.pm
 Test-Smoke-1.70/lib/Test/Smoke/SysInfo/Linux.pm.orig   2017-01-04 
15:27:47.642762728 +0100
-+++ Test-Smoke-1.70/lib/Test/Smoke/SysInfo/Linux.pm2017-01-04 
15:58:21.980953580 +0100
-@@ -23,9 +23,10 @@ sub prepare_sysinfo {
- return if !$self->prepare_proc_cpuinfo();
- 
- for ($self->get_cpu_type()) {
--/arm/   && do {$self->linux_arm(); last};
--/ppc/   && do {$self->linux_ppc(); last};
--/sparc/ && do {$self->linux_sparc(); last};
-+/arm/ && do {$self->linux_arm(); last};
-+/aarch64/ && do {$self->linux_arm(); last};
-+/ppc/ && do {$self->linux_ppc(); last};
-+/sparc/   && do {$self->linux_sparc(); last};
- # default
- $self->linux_generic();
- }
diff --git a/perl-Test-Smoke.spec b/perl-Test-Smoke.spec
index 78ef76a..4700b02 100644
--- a/perl-Test-Smoke.spec
+++ b/perl-Test-Smoke.spec
@@ -1,14 +1,11 @@
 Name:   perl-Test-Smoke
-Version:1.70
-Release:5%{?dist}
+Version:1.71
+Release:1%{?dist}
 Summary:Perl core test smoke suite
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Test-Smoke/
 Source0:
http://www.cpan.org/authors/id/A/AB/ABELTJE/Test-Smoke-%{version}.tar.gz
-# On aarch64, the function used for parsing cpuinfo does not work properly
-# (CPAN RT#119691)
-Patch0: Test-Smoke-1.70-Fix-cpuinfo-for-aarch64.patch
 BuildArch:  noarch
 BuildRequires:  coreutils
 BuildRequires:  findutils
@@ -49,6 +46,7 @@ BuildRequires:  perl(overload)
 # Pod::Usage is not needed for tests
 BuildRequires:  perl(POSIX)
 BuildRequires:  perl(Socket)
+BuildRequires:  perl(System::Info)
 BuildRequires:  perl(Text::ParseWords)
 BuildRequires:  perl(Time::Local)
 BuildRequires:  perl(vars)
@@ -81,7 +79,6 @@ results into an easy to read report.
 
 %prep
 %setup -q -n Test-Smoke-%{version}
-%patch0 -p1
 
 # Ignore output files from find-debuginfo.sh to fix the test 00-manifest.t
 echo '.+\.list' >> MANIFEST.SKIP
@@ -117,6 +114,7 @@ make test
 %{_bindir}/synctree.pl
 %{_bindir}/sysinfo.pl
 %{_bindir}/tsarchive.pl
+%{_bindir}/tsreport.pl
 %{_bindir}/tsrunsmoke.pl
 %{_bindir}/tssendrpt.pl
 %{_bindir}/tssmokeperl.pl
@@ -126,6 +124,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jun 28 2017 Jitka Plesnikova  - 1.71-1
+- 1.71 bump
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
1.70-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
diff --git a/sources b/sources
index a6a62b8..218ec79 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-96087b014b7e4d713b6a3da1bf81ace9  Test-Smoke-1.70.tar.gz
+SHA512 (Test-Smoke-1.71.tar.gz) = 
e3a1a944a5cd4c96423f644220b47bdcfe088c4bff30ac8d7cb7bcf41224b15717f05a10e4b25b44f42d55c1a2f08e110fa4e8ebcc2d2123d4385726633da1e3
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Test-Smoke.git/commit/?h=master=93b01ab889171e4c219d54f9840a2fcc9e88a34f
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded Test-Smoke-1.71.tar.gz for perl-Test-Smoke

[notifications]

e3a1a944a5cd4c96423f644220b47bdcfe088c4bff30ac8d7cb7bcf41224b15717f05a10e4b25b44f42d55c1a2f08e110fa4e8ebcc2d2123d4385726633da1e3
  Test-Smoke-1.71.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Test-Smoke/Test-Smoke-1.71.tar.gz/sha512/e3a1a944a5cd4c96423f644220b47bdcfe088c4bff30ac8d7cb7bcf41224b15717f05a10e4b25b44f42d55c1a2f08e110fa4e8ebcc2d2123d4385726633da1e3/Test-Smoke-1.71.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

[Stephen John Smoogen]

On 28 June 2017 at 07:54, Josh Boyer  wrote:
> On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
>  wrote:
>> On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:
>>>
>>> I cannot argue with the criteria as you have set forth.  However, I
>>> never said we should block the release.  I said it should work on the
>>> architectures it does today.  That is more than x86_64.  We *know* we
>>> have significant interest from multiple parties around Server on other
>>> architectures.  This comes from both the project sponsor and from
>>> parties representing those architectures.  They are even participating
>>> members in the Server WG.  So while you may not hold a Fedora release
>>> for it, I do not think it is out of line to come into a Modular Server
>>> release with the intention of it actually working across multiple CPU
>>> architectures.
>>
>> Well, there is of course potentially a gap between "the intention of it
>> actually working" and...actually working :)
>
> One we bridge well today, given that it works on things other than x86_64.

But does it work by design or accident on those. And I don't mean that
snarkily but in a "we actually haven't looked at making it work and
focused on other parts versus looking at it at all."

In the end, we need to make this a concrete proposal. What resources
are we going to get to make sure that it can work on whatever other
architectures are being added to the list? Will these people be
dedicated to make this work and what are all the groups outside of
either modularity or server group which might be needed to make it
work? And what architectures are we talking about as must haves?




>
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1450709] perl-Test-Smoke-1.71 is available

[bugzilla]

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

Bug 1465494 Summary: Review Request: perl-System-Info - Factory for system 
specific information objects
https://bugzilla.redhat.com/show_bug.cgi?id=1465494

   What|Removed |Added

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



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik changed ppisar's 'watchcommits' permission on rpms/perl-System-Info (master) to 'Obsolete'

[notifications]

jplesnik changed ppisar's 'watchcommits' permission on rpms/perl-System-Info 
(master) to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-System-Info/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik changed perl-sig's 'commit' permission on rpms/perl-System-Info (master) to 'Obsolete'

[notifications]

jplesnik changed perl-sig's 'commit' permission on rpms/perl-System-Info 
(master) to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-System-Info/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik changed ppisar's 'watchbugzilla' permission on rpms/perl-System-Info (master) to 'Obsolete'

[notifications]

jplesnik changed ppisar's 'watchbugzilla' permission on rpms/perl-System-Info 
(master) to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-System-Info/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[Peter Robinson]

On Wed, Jun 28, 2017 at 2:08 PM, Michael Catanzaro
 wrote:
> On Wed, Jun 28, 2017 at 5:52 AM, Tomasz Torcz  wrote:
>>
>>   The same upstream which did not release stable version of Xorg Intel
>> driver
>> for past three years? ;-)
>>   According to the link, the firmwares are needed for HDMI audio, which is
>> quite critical functionality.  HDMI audio for older chipsets did not
>> require binary blobs, so this is kind of regression.
>
>
> We should push back very hard against this. I was under the impression that
> Intel was the open source CPU vendor. If we need binary blobs in the OS to
> make new chips work properly, perhaps Fedora and Red Hat should be heavily
> promoting AMD until Intel decides to change its ways.

I believe all common current generation GPUs need firmware, some of
the intel platforms have needed firmware for audio for some time.

The intel audio firmware is /lib/firmware/intel/dsp_fw_* and the
various nVidia firmware is in /lib/firmware/nvidia/

> (I am hoping AMD doesn't do this too. I have no idea.)

You'd be wrong, check /lib/firmware/amdgpu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[Michael Catanzaro]

On Wed, Jun 28, 2017 at 5:52 AM, Tomasz Torcz  
wrote:
  The same upstream which did not release stable version of Xorg 
Intel driver

for past three years? ;-)
  According to the link, the firmwares are needed for HDMI audio, 
which is

quite critical functionality.  HDMI audio for older chipsets did not
require binary blobs, so this is kind of regression.


We should push back very hard against this. I was under the impression 
that Intel was the open source CPU vendor. If we need binary blobs in 
the OS to make new chips work properly, perhaps Fedora and Red Hat 
should be heavily promoting AMD until Intel decides to change its ways.


(I am hoping AMD doesn't do this too. I have no idea.)

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1465702] perl-Net-HL7-0.82 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
wfp's perl-Net-HL7-0.82-1.fc27 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=912771

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

wfp pushed to perl-Net-HL7 (master). "Update to version 0.82"

[notifications]

From c680d7c0356f2bf6779eb377695df5b9379c5a6e Mon Sep 17 00:00:00 2001
From: Bill Pemberton 
Date: Wed, 28 Jun 2017 08:58:57 -0400
Subject: Update to version 0.82

---
 .gitignore| 1 +
 perl-Net-HL7.spec | 7 +--
 sources   | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 56fa859..228dff6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Net-HL7-0.81.tar.gz
+/Net-HL7-0.82.tar.gz
diff --git a/perl-Net-HL7.spec b/perl-Net-HL7.spec
index e3c9545..c41df29 100644
--- a/perl-Net-HL7.spec
+++ b/perl-Net-HL7.spec
@@ -1,6 +1,6 @@
 Name:  perl-Net-HL7
-Version:   0.81
-Release:   6%{?dist}
+Version:   0.82
+Release:   1%{?dist}
 Summary:   Simple perl API for HL7 messages
 License:   Beerware and (GPL+ or Artistic)
 Group: Development/Libraries
@@ -63,6 +63,9 @@ make test
 %{_mandir}/man3/Net::HL7*.3pm*
 
 %changelog
+* Wed Jun 28 2017 Bill Pemberton  - 0.82-1
+- update to version 0.82
+
 * Mon Jun 05 2017 Jitka Plesnikova  - 0.81-6
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index ac9502a..a1ecc75 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-190c40279520093a4a76be7c1e7fdf02  Net-HL7-0.81.tar.gz
+SHA512 (Net-HL7-0.82.tar.gz) = 
bf36d81c89b81d1f3253f52845fd714d765c9e16b5ad14b00391c109e98d7b7529094dca17211f651d66d4ddbd7627daaf9f4206742a24eb313cd37fd44f9a4c
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Net-HL7.git/commit/?h=master=c680d7c0356f2bf6779eb377695df5b9379c5a6e
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

wfp uploaded Net-HL7-0.82.tar.gz for perl-Net-HL7

[notifications]

bf36d81c89b81d1f3253f52845fd714d765c9e16b5ad14b00391c109e98d7b7529094dca17211f651d66d4ddbd7627daaf9f4206742a24eb313cd37fd44f9a4c
  Net-HL7-0.82.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Net-HL7/Net-HL7-0.82.tar.gz/sha512/bf36d81c89b81d1f3253f52845fd714d765c9e16b5ad14b00391c109e98d7b7529094dca17211f651d66d4ddbd7627daaf9f4206742a24eb313cd37fd44f9a4c/Net-HL7-0.82.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Comaintaining of lv2-x42-plugins

[Guido Aulisi]

Hi,
I'd like to help update lv2-x42-plugins to the latest upstream version,
so I asked for acls on pkgdb.
As pkgdb is near EOL, I'm also writing here...

Guido Aulisi

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25: cxacru module (ADSL Modem USB) fail to load its firmware at boot time

[Dario Lesca]

I have migrate my home server from Fedora 11 to Fedora 25 with a new
installation.

All work fine except the load firmware of the cxacru module (ADSL Modem
USB) at boot time, after a poweroff and unplug/plug the AC power cable.

If I try reload the modules manually when the server is started I get
the same error and the firmware is not loaded.

If I disconnect and reconnect modem USB when the server is on, the
cxacru module load its firmware without problem and I can load the ppp
interface property .

This is log message at boot time:

> giu 28 09:11:18 igloo.home.solinos.it kernel: rt61pci :05:00.0 wlp5s0: 
> renamed from wlan0
> giu 28 09:11:18 igloo.home.solinos.it crda[811]: setting regulatory domain to 
> IT based on timezone (Europe/Rome)
> giu 28 09:11:19 igloo.home.solinos.it systemd[1]: Found device 
> /dev/fedora/multimedia.
> giu 28 09:11:19 igloo.home.solinos.it kernel: cxacru 2-1.1:1.0: receive of cm 
> 0x90 failed (-104)
> giu 28 09:11:19 igloo.home.solinos.it kernel: usbcore: registered new 
> interface driver cxacru
> giu 28 09:11:19 igloo.home.solinos.it kernel: cxacru 2-1.1:1.0: found 
> firmware cxacru-fw.bin
> giu 28 09:11:19 igloo.home.solinos.it kernel: cxacru 2-1.1:1.0: loading 
> firmware
> giu 28 09:11:19 igloo.home.solinos.it kernel: cxacru 2-1.1:1.0: Firmware 
> upload failed: -32
> giu 28 09:11:19 igloo.home.solinos.it kernel: cxacru 2-1.1:1.0: send of cm 
> 0x90 failed (-32)
> giu 28 09:11:19 igloo.home.solinos.it systemd[1]: Found device 
> /dev/fedora/temp.
> giu 28 09:11:19 igloo.home.solinos.it systemd[1]: Found device 
> /dev/mapper/fedora-var.
> giu 28 09:11:19 igloo.home.solinos.it systemd[1]: Found device 
> /dev/mapper/fedora-home.
> giu 28 09:11:19 igloo.home.solinos.it systemd[1]: Found device 
> /dev/fedora/lv_virt.
> giu 28 09:11:20 igloo.home.solinos.it lvm[775]:   9 logical volume(s) in 
> volume group "fedora" now active
> 

This is log message when all work fine:

> giu 28 12:12:57 igloo.home.solinos.it kernel: usbcore: registered new 
> interface driver cxacru
> giu 28 12:12:57 igloo.home.solinos.it kernel: cxacru 2-1.1:1.0: found 
> firmware cxacru-fw.bin
> giu 28 12:12:57 igloo.home.solinos.it kernel: cxacru 2-1.1:1.0: loading 
> firmware
> giu 28 12:12:58 igloo.home.solinos.it kernel: cxacru 2-1.1:1.0: starting 
> device
> giu 28 12:12:59 igloo.home.solinos.it NetworkManager[1055]:   
> [1498644779.6061] manager: (cxacru0): new ADSL device 
> (/org/freedesktop/NetworkManager/Devices/4)
> giu 28 12:12:59 igloo.home.solinos.it NetworkManager[1055]:   
> [1498644779.6064] device (cxacru0): state change: unmanaged -> unavailable 
> (reason 'managed') [10 20 2]
> giu 28 12:12:59 igloo.home.solinos.it kernel: cxacru0: ADSL USB MODEM 
> (usb-:00:1d.0-1.1) 00:04:ed:54:e2:53
> giu 28 12:12:59 igloo.home.solinos.it kernel: ATM dev 0: ADSL state: running
> giu 28 12:12:59 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: down
> giu 28 12:13:03 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: 
> attempting to activate
> giu 28 12:13:05 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: down
> giu 28 12:13:07 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: 
> attempting to activate
> giu 28 12:13:09 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: down
> giu 28 12:13:11 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: 
> attempting to activate
> giu 28 12:13:19 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: training
> giu 28 12:13:21 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: channel 
> analysis
> giu 28 12:13:26 igloo.home.solinos.it kernel: ATM dev 0: ADSL line: up (800 
> kb/s down | 320 kb/s up)
> giu 28 12:13:29 igloo.home.solinos.it NetworkManager[1055]:   
> [1498644809.6502] device (cxacru0): link connected
> giu 28 12:13:29 igloo.home.solinos.it NetworkManager[1055]:   
> [1498644809.6505] device (cxacru0): state change: unavailable -> disconnected 
> (reason 'carrier-changed') [20 30 40]

I have do a script to run after boot in order to load cxacru module and ppp0 
interface.
But I must unplug and reattach manually the usb cable before run this script

There is some way (command line) to simulate unplug/plug of Modem USB? 

Someone have some suggest?

Many thanks 

-- 
Dario Lesca
(inviato dal mio Linux Fedora 25 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1465888] New: perl-Prima-1.52 is available

[bugzilla]

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

Bug ID: 1465888
   Summary: perl-Prima-1.52 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Prima
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.52
Current version/release in rawhide: 1.51-2.fc27
URL: http://search.cpan.org/dist/Prima/

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

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

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

[Josh Boyer]

On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
 wrote:
> On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:
>>
>> I cannot argue with the criteria as you have set forth.  However, I
>> never said we should block the release.  I said it should work on the
>> architectures it does today.  That is more than x86_64.  We *know* we
>> have significant interest from multiple parties around Server on other
>> architectures.  This comes from both the project sponsor and from
>> parties representing those architectures.  They are even participating
>> members in the Server WG.  So while you may not hold a Fedora release
>> for it, I do not think it is out of line to come into a Modular Server
>> release with the intention of it actually working across multiple CPU
>> architectures.
>
> Well, there is of course potentially a gap between "the intention of it
> actually working" and...actually working :)

One we bridge well today, given that it works on things other than x86_64.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[Sérgio Basto]

On Wed, 2017-06-28 at 05:20 -0400, David Airlie wrote:
> > I ran into this today:
> > https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
> > 
> > DRM firmware is loaded by default. HuC and GuC are not. Things work
> > without them, and things work with them loaded. So what's the
> > pro/con
> > and if there's a pro, why isn't it the kernel default? Seems like
> > if
> > it should be default, either upstream should set them as the
> > default,
> > or the CPU/GPU should ask for it?
> 
> I expect when upstream decided they are stable and useful enough,
> upstream
> will enable them. I'm not fully sure how useful they are, I think
> they
> might possibly enable lower power states, but also nasty bugs.


And Ironlakes [1] ? 

Can I get any better performance, if I try enable RC6 p-states ? by
this link [2] is for 4th-gen ...

Dell release an update for BIOS [3] 

Best regards, 

[1]
Xorg.0.log
[  1122.762] (II) intel(0): SNA initialized with Ironlake (gen5)
backend

dmesg | grep drm 
[   22.58] [drm] RC6 disabled, disabling runtime PM support


[2]
https://superuser.com/a/783944/176412


[3] 
Dell Latitude E6410 System BIOS
This package provides the BIOS update for Dell Latitude E6410/6410ATG
and is supported on Latitude E6410/6410ATG models (...)

Fixes:
- Updated Intel ME Firmware to address security advisory CVE-2017-5689
/ INTEL-SA-00075.



-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[Bastien Nocera]

- Original Message -
> On Wed, Jun 28, 2017 at 05:20:13AM -0400, David Airlie wrote:
> > 
> > > I ran into this today:
> > > https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
> > > 
> > > DRM firmware is loaded by default. HuC and GuC are not. Things work
> > > without them, and things work with them loaded. So what's the pro/con
> > > and if there's a pro, why isn't it the kernel default? Seems like if
> > > it should be default, either upstream should set them as the default,
> > > or the CPU/GPU should ask for it?
> > 
> > I expect when upstream decided they are stable and useful enough, upstream
> > will enable them. I'm not fully sure how useful they are, I think they
> > might possibly enable lower power states, but also nasty bugs.
> 
>   The same upstream which did not release stable version of Xorg Intel driver
> for past three years? ;-)
>   According to the link, the firmwares are needed for HDMI audio, which is
> quite critical functionality.  HDMI audio for older chipsets did not
> require binary blobs, so this is kind of regression.

That might be the reason why I had to blacklist the snd-hdmi-lpe-audio module
on my system. Pulseaudio crashed trying to access the HDMI audio device.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[Tomasz Torcz]

On Wed, Jun 28, 2017 at 05:20:13AM -0400, David Airlie wrote:
> 
> > I ran into this today:
> > https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
> > 
> > DRM firmware is loaded by default. HuC and GuC are not. Things work
> > without them, and things work with them loaded. So what's the pro/con
> > and if there's a pro, why isn't it the kernel default? Seems like if
> > it should be default, either upstream should set them as the default,
> > or the CPU/GPU should ask for it?
> 
> I expect when upstream decided they are stable and useful enough, upstream
> will enable them. I'm not fully sure how useful they are, I think they
> might possibly enable lower power states, but also nasty bugs.

  The same upstream which did not release stable version of Xorg Intel driver
for past three years? ;-)
  According to the link, the firmwares are needed for HDMI audio, which is
quite critical functionality.  HDMI audio for older chipsets did not 
require binary blobs, so this is kind of regression.

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-MetaCPAN-API-Tiny (epel7). "Switch to v1 API and tidy up a bit (..more)"

[notifications]

From e4bd87c7129d27b96f542e0d8de3a6052be37505 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Wed, 28 Jun 2017 10:37:50 +0100
Subject: Switch to v1 API and tidy up a bit

- Switch to v1 API (CPAN RT#122004)
- Simplify find command using -delete
- Use %license
- Drop redundant Group: tag
---
 MetaCPAN-API-Tiny-1.131730-v1api.patch | 11 +++
 perl-MetaCPAN-API-Tiny.spec| 22 --
 2 files changed, 27 insertions(+), 6 deletions(-)
 create mode 100644 MetaCPAN-API-Tiny-1.131730-v1api.patch

diff --git a/MetaCPAN-API-Tiny-1.131730-v1api.patch 
b/MetaCPAN-API-Tiny-1.131730-v1api.patch
new file mode 100644
index 000..b366cd4
--- /dev/null
+++ b/MetaCPAN-API-Tiny-1.131730-v1api.patch
@@ -0,0 +1,11 @@
+--- lib/MetaCPAN/API/Tiny.pm
 lib/MetaCPAN/API/Tiny.pm
+@@ -23,7 +23,7 @@ sub new {
+ if $params{ua_args} && ref($params{ua_args}) ne 'ARRAY';
+ 
+ my $self = +{
+-base_url => $params{base_url} || 'http://api.metacpan.org/v0',
++base_url => $params{base_url} || 'http://fastapi.metacpan.org/v1',
+ ua => $params{ua} || HTTP::Tiny->new(
+ $params{ua_args}
+ ? @{$params{ua_args}}
diff --git a/perl-MetaCPAN-API-Tiny.spec b/perl-MetaCPAN-API-Tiny.spec
index 3236ff2..6dcb909 100644
--- a/perl-MetaCPAN-API-Tiny.spec
+++ b/perl-MetaCPAN-API-Tiny.spec
@@ -2,12 +2,12 @@
 
 Name:  perl-MetaCPAN-API-Tiny
 Version:   1.131730
-Release:   3%{?dist}
+Release:   4%{?dist}
 Summary:   A Tiny API client for MetaCPAN
-Group: Development/Libraries
 License:   GPL+ or Artistic
 URL:   https://metacpan.org/release/MetaCPAN-API-Tiny
 Source0:   
http://cpan.metacpan.org/authors/id/N/NP/NPEREZ/MetaCPAN-API-Tiny-%{version}.tar.gz
+Patch0:MetaCPAN-API-Tiny-1.131730-v1api.patch
 BuildArch: noarch
 # Build
 BuildRequires: perl(ExtUtils::MakeMaker) >= 6.30
@@ -48,14 +48,17 @@ Testing
 %prep
 %setup -q -n MetaCPAN-API-Tiny-%{version}
 
+# Switch to v1 API (CPAN RT#122004)
+%patch0
+
 %build
 perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-%{_fixperms} %{buildroot}
+find %{buildroot} -type f -name .packlist -delete
+%{_fixperms} -c %{buildroot}
 
 %check
 %if !%{with network_tests}
@@ -69,11 +72,18 @@ mv ./{author,module,pod,release,source}.t t/
 %endif
 
 %files
-%doc Changes LICENSE README
+%license LICENSE
+%doc Changes README
 %{perl_vendorlib}/MetaCPAN/
-%{_mandir}/man3/MetaCPAN::API::Tiny.3pm*
+%{_mandir}/man3/MetaCPAN::API::Tiny.3*
 
 %changelog
+* Wed Jun 28 2017 Paul Howarth  - 1.131730-4
+- Switch to v1 API (CPAN RT#122004)
+- Simplify find command using -delete
+- Use %%license
+- Drop redundant Group: tag
+
 * Fri Feb  7 2014 Paul Howarth  - 1.131730-3
 - Don't run tests that require network access by default
 
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-MetaCPAN-API-Tiny.git/commit/?h=epel7=e4bd87c7129d27b96f542e0d8de3a6052be37505
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Peter Robinson]

>> On Wed, Jun 28, 2017 at 10:03 AM, Björn Persson  wrote:
>>> t...@fedoraproject.org wrote:
 floppy-support bruno  162 weeks ago
>>>
>>> So are floppies now definitely a thing of the past according to Fedora?
>>
>> Well they definitely are a thing of the past, there's no doubt there,
>> the question is whether they are still used :-) I would argue printers
>> are a thing of the past but sadly there's no such thing as a paperless
>> office yet.
>
> How hard do we want to make things with people with legacy technology? While 
> they may not be actively used, they do still exist.

Sure, so do paper tape and punch cards there's a number of issues
but primarily people interested in the technology both maintaining it
and actually testing it to ensure it works. For example we've had a
kernel patch since 2010 that disables the auto loading of the floppy
kernel module so people would have to know manually load it. All this
package does is to actually enable the auto loading of that module so
it works OOTB for those that know to install the package.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Daniel P. Berrange]

On Wed, Jun 28, 2017 at 11:03:09AM +0200, Björn Persson wrote:
> t...@fedoraproject.org wrote:
> > floppy-support bruno  162 weeks ago 
> 
> So are floppies now definitely a thing of the past according to Fedora?

This message is simply Fedora is saying that the package is being retired
because it has broken dependencies, which the maintainer has not fixed in
a timely manner. Perhaps the maintainer doesn't care about the package any
more, or doesn't have time for it, or any number of other reasons. That's
just one maintainer though. If someone else cares about this package,
they could volunteer to become maintainer, and fix the package, at which
point there is no requirement for it to be retired.

Now if the kernel's 'floppy' module is removed from the build, that would
be an explicit statement that floppies are no longer supported, but AFAIK,
all we've done in the kernel is turn off auto-loading of 'floppy' - it can
still be loaded explicitly.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[David Airlie]

> I ran into this today:
> https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
> 
> DRM firmware is loaded by default. HuC and GuC are not. Things work
> without them, and things work with them loaded. So what's the pro/con
> and if there's a pro, why isn't it the kernel default? Seems like if
> it should be default, either upstream should set them as the default,
> or the CPU/GPU should ask for it?

I expect when upstream decided they are stable and useful enough, upstream
will enable them. I'm not fully sure how useful they are, I think they
might possibly enable lower power states, but also nasty bugs.


Dave.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Graham Leggett]

On 28 Jun 2017, at 11:09 AM, Peter Robinson  wrote:

> On Wed, Jun 28, 2017 at 10:03 AM, Björn Persson  wrote:
>> t...@fedoraproject.org wrote:
>>> floppy-support bruno  162 weeks ago
>> 
>> So are floppies now definitely a thing of the past according to Fedora?
> 
> Well they definitely are a thing of the past, there's no doubt there,
> the question is whether they are still used :-) I would argue printers
> are a thing of the past but sadly there's no such thing as a paperless
> office yet.

How hard do we want to make things with people with legacy technology? While 
they may not be actively used, they do still exist.

Regards,
Graham
—
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Peter Robinson]

On Wed, Jun 28, 2017 at 10:03 AM, Björn Persson  wrote:
> t...@fedoraproject.org wrote:
>> floppy-support bruno  162 weeks ago
>
> So are floppies now definitely a thing of the past according to Fedora?

Well they definitely are a thing of the past, there's no doubt there,
the question is whether they are still used :-) I would argue printers
are a thing of the past but sadly there's no such thing as a paperless
office yet.

> (A power supply that I recently bought came with an adapter cable for
> powering a diskette drive. :-) )

They can be used for powering other things though too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Björn Persson]

t...@fedoraproject.org wrote:
> floppy-support bruno  162 weeks ago 

So are floppies now definitely a thing of the past according to Fedora?

(A power supply that I recently bought came with an adapter cable for
powering a diskette drive. :-) )

Björn Persson


pgpyJ_ehHyNiC.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Golang 1.9

[Jakub Cajka]

- Original Message -
> From: "Dominik 'Rathann' Mierzejewski" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, June 22, 2017 1:40:35 PM
> Subject: Re: F27 System Wide Change: Golang 1.9
> 
> On Thursday, 22 June 2017 at 13:17, Jakub Cajka wrote:
> > - Original Message -
> > > From: "Tony Breeds" 
> > > To: devel@lists.fedoraproject.org
> > > Sent: Thursday, June 22, 2017 2:03:44 AM
> > > Subject: Re: F27 System Wide Change: Golang 1.9
> > > 
> > > On Wed, Jun 21, 2017 at 10:06:17AM +0200, Jan Kurik wrote:
> > > 
> > > 
> > > 
> > > > Along with the rebase I do propose to drop ppc64 from Go
> > > > architectures(effectively disabling build of all packages adhering to
> > > > draft Go packaging guidelines) as ppc64 port of "GC" is not feature
> > > > complete(never were) and with Go 1.9 "GC" will be supporting only
> > > > Power 8 and up.
> > > 
> > > Just for clarity, you're ppc64le would remain supported.  Correct?
> > 
> > Yes. That is correct,
> 
> Can you make sure that the Go packaging guidelines draft makes it into
> the official guidelines?
> 
> Regards,
> Dominik

I have spoke about it with jchaloupka(main driver/author of guidelines) and we 
should be set to go, after I adjust them for the ppc64 change.

JC

> --
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org
> "Faith manages."
> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: Remove SSH-1 from OpenSSH clients

[Jan Kurik]

= Proposed Self Contained Change: Remove SSH-1 from OpenSSH clients =
https://fedoraproject.org/wiki/Changes/Remove_SSH-1_from_OpenSSH

Change owner(s):
* Jakub Jelen 

Upstream removes support for SSH-1 protocol and we plan to do the same
in Fedora. The protocol is years obsolete and not even supported in
current default binaries (only in openssh-clients-ssh1 subpackage).


== Detailed Description ==
SSH-1 protocol was introduced more than 20 years ago and is no longer
considered secure. OpenSSH package in Fedora is built without SSH-1
protocol since 2015 (SSH-1 clients are available in
openssh-clients-ssh1 subpackage). OpenSSH upstream plans to remove the
code completely in next release, which prevents us from using this
technique further and remove the support completely (unless there will
be significant demand for compat package).

== Scope ==
* Proposal owners:
Remove subpackage openssh-clients-ssh1 and potentially create
compat-openssh-clients-7.5 package with clients supporting SSH-1
protocol.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
#6867 https://pagure.io/releng/issues/6867

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: Remove SSH-1 from OpenSSH clients

[Jan Kurik]

= Proposed Self Contained Change: Remove SSH-1 from OpenSSH clients =
https://fedoraproject.org/wiki/Changes/Remove_SSH-1_from_OpenSSH

Change owner(s):
* Jakub Jelen 

Upstream removes support for SSH-1 protocol and we plan to do the same
in Fedora. The protocol is years obsolete and not even supported in
current default binaries (only in openssh-clients-ssh1 subpackage).


== Detailed Description ==
SSH-1 protocol was introduced more than 20 years ago and is no longer
considered secure. OpenSSH package in Fedora is built without SSH-1
protocol since 2015 (SSH-1 clients are available in
openssh-clients-ssh1 subpackage). OpenSSH upstream plans to remove the
code completely in next release, which prevents us from using this
technique further and remove the support completely (unless there will
be significant demand for compat package).

== Scope ==
* Proposal owners:
Remove subpackage openssh-clients-ssh1 and potentially create
compat-openssh-clients-7.5 package with clients supporting SSH-1
protocol.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
#6867 https://pagure.io/releng/issues/6867

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 610 emails for a branch import in dist git?

[Parag Nemade]

On Wed, Jun 28, 2017 at 12:29 PM, Michal Novotny  wrote:

> Can you, please, show the emails or just one of them?
>
>

https://lists.fedoraproject.org/archives/search?mlist=scm-commits%40lists.fedoraproject.org=audacious-plugins



> On Tue, Jun 27, 2017 at 11:34 PM, Michael Schwendt 
> wrote:
>
>> Whoever set up that service, seriously?
>>
>> Why would I receive 610 emails for activity in "epel7"? For packages with
>> a longer git history, it will likely be thousands of emails.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
Parag
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org