[389-devel] Please Review 49715 - account functionality

[William Brown]

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

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



—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1685532] Upgrade perl-Pod-Tests to 1.20

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Pod-Tests-1.20-1.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-3e736d741b

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

[Bug 1685532] Upgrade perl-Pod-Tests to 1.20

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Pod-Tests-1.20-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-4809dca134

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

[Bug 1685532] Upgrade perl-Pod-Tests to 1.20

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-Pod-Tests-1.20-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-ca512185c7

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

Re: modular repositories in mock configs: please don't

[Ralf Corsepius]

On 3/5/19 9:08 AM, Adam Samalik wrote:

On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth  wrote:


On 3/4/19 3:04 AM, Petr Šabata wrote:

You can view them as virtual repositories with dependencies.  I
think that might be the simplest way to put it.

You can try playing with fedmod to generate your modulemd file or
you can just write it from scratch; it's not all that complicated.


Why should I care? Please, win me over. (I'm being serious.)



I think you should care if:

a) You need to maintain multiple versions of the same app/runtime/set of
tools tools in Fedora (or an alternative to something that already exists),
or
b) You only want to maintain one source branch per package for all Fedora
releases, or
c) You could benefit from having a build recipe in case you maintain
app/runtime/set of tools tools represented by multiple packages that need
to be built in the right order

But if any of the above is something that you need/want to do, then
Modularity won't help you nor hurt you in any way.


All of what list above can be handled at the rpm-level by means of 
"proper" system integration.


That said, to me, modules are an approach to circumvent system integration.

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

tracebacks while "git push"ing to Fedora's git

[Ralf Corsepius]

Hi,

when "git push"ing updates to Fedora's git, I am currently encountering 
this kind of tracebacks:


$ git push
Total 0 (delta 0), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 1 commits
remote: Traceback (most recent call last):
remote:   File 
"/usr/lib/python2.7/site-packages/pagure/hooks/__init__.py", line 394, 
in run_project_hooks

remote: changes=changes,
remote:   File 
"/usr/lib/python2.7/site-packages/pagure/hooks/__init__.py", line 111, 
in runhook

remote: changes=changes,
remote:   File 
"/usr/lib/python2.7/site-packages/pagure/hooks/default.py", line 336, in 
post_receive

remote: but_uids=pr_uids,
remote:   File "/usr/lib/python2.7/site-packages/celery/local.py", line 
191, in __call__

remote: return self._get_current_object()(*a, **kw)
remote:   File "/usr/lib/python2.7/site-packages/celery/app/task.py", 
line 375, in __call__

remote: return self.run(*args, **kwargs)
remote:   File 
"/usr/lib/python2.7/site-packages/pagure/lib/tasks_utils.py", line 36, 
in decorated_function

remote: return function(self, session, *args, **kwargs)
remote:   File "/usr/lib/python2.7/site-packages/pagure/lib/tasks.py", 
line 700, in refresh_pr_cache

remote: session, project, but_uids=but_uids
remote:   File "/usr/lib/python2.7/site-packages/pagure/lib/query.py", 
line 3318, in reset_status_pull_request
remote: {model.PullRequest.merge_status: None}, 
synchronize_session=False
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2796, 
in update

remote: update_op.exec_()
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 
897, in exec_

remote: self._do_exec()
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 
995, in _do_exec

remote: update_stmt, params=self.query._params)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 
991, in execute

remote: bind, close_with_result=True).execute(clause, params or {})
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
729, in execute

remote: return meth(self, multiparams, params)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py", line 
322, in _execute_on_connection
remote: return connection._execute_clauseelement(self, multiparams, 
params)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
826, in _execute_clauseelement

remote: compiled_sql, distilled_params
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
958, in _execute_context

remote: context)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1159, in _handle_dbapi_exception

remote: exc_info
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py", line 
199, in raise_from_cause

remote: reraise(type(exception), exception, tb=exc_tb)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
951, in _execute_context

remote: context)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 
436, in do_execute

remote: cursor.execute(statement, parameters)
remote: ProgrammingError: (ProgrammingError) permission denied for 
relation pull_requests
remote:  'UPDATE pull_requests SET merge_status=%(merge_status)s, 
last_updated=%(last_updated)s WHERE pull_requests.project_id = 
%(project_id_1)s AND pull_requests.status = %(status_1)s' 
{'project_id_1': 14960, 'last_updated': datetime.datetime(2019, 3, 6, 3, 
55, 50, 495151), 'merge_status': None, 'status_1': u'Open'}

remote: Sending to redis to send commit notification emails
remote: * Publishing information for 1 commits
remote:
remote: Create a pull-request for f30
remote: 
https://src.fedoraproject.org/rpms/perl-Pod-Tests/diff/master..f30

remote:
To ssh://pkgs.fedoraproject.org/rpms/perl-Pod-Tests
   723ef5b..e29a00d  f30 -> f30

What's going on here?

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

[389-devel] Please Review: 49655 rm doap file

[William Brown]

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

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



--
Sincerely,

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

Reminder: Daylight Saving/Summer Time changes soon

[Ben Cotton]

Hi everyone,

As the Earth continues to orbit the sun with an axial tilt of
approximately 23.5 degrees, various political bodies are preparing to
change the clock. Daylight Saving Time (or Summer Time in some places)
will soon be beginning or ending. This means that some of your regular
meetings may soon shift relative to your local time. Be sure to check
Fedocal[1] for the correct times. Some meetings are scheduled in the
UTC timezone, others are in another time zone (e.g. America/New York).
A full list of time changes by country is available online[2], but a
few highlights are listed below.

Australia — ends 7 April (with exceptions[2])
Canada — begins 10 March (with exceptions[2])
Czech Republic — begins 31 March
France — begins 31 March
Germany — begins 31 March
United Kingdom — begins 31 March
United States — begins 10 March (with exceptions[2])

[1] https://apps.fedoraproject.org/calendar/
[2] https://www.timeanddate.com/time/dst/2019.html

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reminder: Daylight Saving/Summer Time changes soon

[Ben Cotton]

Hi everyone,

As the Earth continues to orbit the sun with an axial tilt of
approximately 23.5 degrees, various political bodies are preparing to
change the clock. Daylight Saving Time (or Summer Time in some places)
will soon be beginning or ending. This means that some of your regular
meetings may soon shift relative to your local time. Be sure to check
Fedocal[1] for the correct times. Some meetings are scheduled in the
UTC timezone, others are in another time zone (e.g. America/New York).
A full list of time changes by country is available online[2], but a
few highlights are listed below.

Australia — ends 7 April (with exceptions[2])
Canada — begins 10 March (with exceptions[2])
Czech Republic — begins 31 March
France — begins 31 March
Germany — begins 31 March
United Kingdom — begins 31 March
United States — begins 10 March (with exceptions[2])

[1] https://apps.fedoraproject.org/calendar/
[2] https://www.timeanddate.com/time/dst/2019.html

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: Fedora 30 Beta Freeze

[Rafal Luzynski]

5.03.2019 04:20 Mohan Boddu  wrote:
> [...]
> Finally, today is also the Software String freeze[7], which means that
> strings marked for translation in Fedora-
> translated projects should not now be changed for Fedora 30.

Thanks for the reminders. The link [1] says that the software string
freeze was one month ago. Today is the software translation deadline.
See also: Translation Tasks. [8]

Regards,

Rafal


> [1] https://fedoraproject.org/wiki/Releases/30/Schedule
> [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
> [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
> [4] https://fedoraproject.org/wiki/Milestone_freezes
> [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
> [6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
> [7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy

[8] https://fedorapeople.org/groups/schedule/f-30/f-30-trans-tasks.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F31 Self-Contained Change proposal: Mono 5

[Ben Cotton]

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

== Summary ==
Update the Mono stack in Fedora from 4.8 to 5.*

== Owner ==
* Name: [[User:tpokorra|Timotheus Pokorra]]
* Email: tpoko...@fedoraproject.org

== Detailed Description ==
Upgrading to Mono 5 has been delayed because Mono 5 compiles by
default with csc rather than msc, and makes use of binary reference
assemblies.

Only in the past months an effort was made to build Mono from source,
as described in this upstream issue:
https://github.com/mono/mono/issues/7445
This issue contains a description how the build was done for Debian so
that building from itself is possible, using msc instead of csc, and
rebuilding the reference assemblies from source.

Mono requires itself to build. The Mono version 4.8 currently included
in Fedora is too old to build version 5. At the moment on
[https://copr.fedorainfracloud.org/coprs/tpokorra/mono-5.18/ copr] we
use monolite, a little version of mono compiler, and the .NET 4.7.1
reference assemblies, all shipped in the tarball for first build time.
The sources of the spec file and the required patch files are
currently maintained on
[https://github.com/tpokorra/mono-5.x-fedora/tree/master/mono-5.18
Github].

We would like to request permission to make a one time exception of
the rule for building mono 5.18.0-1 using monolite and the reference
assemblies, later make mono depend again on itself and rebuild mono
5.18.0-2 using mono-5.18.0-1.

Steps for bootstrapping:

* The Monolite binaries are included in the Mono tarball which is
provided by upstream. See also
http://www.mono-project.com/docs/advanced/monolite/
** Monolite is a minimal binary distribution of mcs. This is the
compiler that is able to build the rest of Mono.
* The binary reference assemblies are included in the Mono tarball
which is provided by upstream. The tarball also includes the sources
of the reference assemblies, which are maintained here:
https://github.com/dotnet/source-build
* In the spec file, we usually delete all dlls and executables before
the build section.
* For the bootstrap, we would once keep the monolite binaries and some
binary reference assemblies.
* In the bootstrap, we rebuild the reference assemblies and include
them in the mono-devel package, as well as the mono compiler.
* After Mono has been built for all primary and secondary
architectures, we enable the deletion of the binaries again in the
spec file.

== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software -
we should have the most recent release of Mono 5.x

It will have the ability to run cross-platform applications that
require compatibility with Microsoft .NET Framework 4.7 and later.

We already have issues upgrading packages like sharpziplib because the
latest upstream version uses new compiler features that are not
included in Mono 4.8 (see
https://bugzilla.redhat.com/show_bug.cgi?id=1601129).

This will also resolve the issues we have because Mono 4.8 does not
build on ppc64 anymore (see
https://bugzilla.redhat.com/show_bug.cgi?id=1588734).

== Scope ==
* Proposal owners:
Update mono spec and build in copr and/or koji until is ready.
Members of the Mono SIG can rebuild their packages with Mono 5, but
tests with keepass for example show that it works fine without
rebuilding even with Mono 5.18. Rebuild of all packages depending on
Mono can happen during the regular mass rebuild.

* Other developers: 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)

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

Tests with keepass without rebuilding keepass worked fine on Mono 5.18.

== How To Test ==
N/A (not a System Wide Change)

== Dependencies ==
This is not a system wide change, but only affects packages depending
on Mono, and should be managed by the members of the [[SIGs/Mono|Mono
SIG]].

Here is a list of packages that require mono-core in Rawhide,
generated with this command: dnf repoquery
--enablerepo=fedora-source --whatrequires mono-core | grep -v
i686

This list even includes packages that are being built from the mono
package (eg. mono-devel and others).


Last metadata expiration check: 0:00:56 ago on Fri Mar  1 23:42:49 2019.
COPASI-0:4.24.197-6.fc30.src
avahi-sharp-0:0.7-18.fc30.x86_64
avahi-ui-sharp-0:0.7-18.fc30.x86_64
banshee-0:2.6.2-32.fc30.x86_64
banshee-community-extensions-0:2.4.0-22.fc30.x86_64
bareftp-0:0.3.12-3.fc30.x86_64
bless-0:0.6.0-26.fc30.x86_64
boo-0:0.9.7.0-11.fc30.x86_64
cdcollect-0:0.6.0-32.fc30.x86_64
dbus-sharp-2:0.8.1-8.fc30.x86_64
dbus-sharp-glib-0:0.6.0-6.fc30.x86_64
gbrainy-1:2.3.5-3.fc30.x86_64
gdata-sharp-0:1.4.0.2-24.fc30.x86_64
gio-sharp-0:0.3-21.fc30.x86_64
gkeyfile-sharp-0:0.1-26.fc30.x86_64
gmime-sharp-0:2.6.23-7.fc30.x86_64
gnome-desktop-sharp-0:2.26.0-35.fc30.x86_64
gnome-do-0:0.95.3-13.fc30.x86_64
gnome-guitar-0:0.8.1-28.fc30.x86_64

Re: The state of Zanata Python client (Python 3 support)

[Rafal Luzynski]

Hi,

Somebody fix me if I'm wrong but as far as I know Python Zanata
client has never been an official client of Zanata. It has always
been just community supported. The official client RPM package is
called zanata-client, its main command line tool is /usr/bin/zanata-cli,
and it is written in Java. This may be the proper solution for you
instead of the Python client. But both the official Zanata client and
whole Zanata have been... not really officially abandoned but just all
original developers no longer work on this.

There was a discussion recently that maybe Zanata should be totally
dropped and replaced with Weblate. Sorry for no links, I'm too tired
to find them now.

Now looking at your email address which says "@redhat.com" I think
that it should be me asking you about the future of Zanata because
it seems that the decisions have been made inside your company rather
than by the outer community.

HTH. Regards,

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

F31 Self-Contained Change proposal: Mono 5

[Ben Cotton]

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

== Summary ==
Update the Mono stack in Fedora from 4.8 to 5.*

== Owner ==
* Name: [[User:tpokorra|Timotheus Pokorra]]
* Email: tpoko...@fedoraproject.org

== Detailed Description ==
Upgrading to Mono 5 has been delayed because Mono 5 compiles by
default with csc rather than msc, and makes use of binary reference
assemblies.

Only in the past months an effort was made to build Mono from source,
as described in this upstream issue:
https://github.com/mono/mono/issues/7445
This issue contains a description how the build was done for Debian so
that building from itself is possible, using msc instead of csc, and
rebuilding the reference assemblies from source.

Mono requires itself to build. The Mono version 4.8 currently included
in Fedora is too old to build version 5. At the moment on
[https://copr.fedorainfracloud.org/coprs/tpokorra/mono-5.18/ copr] we
use monolite, a little version of mono compiler, and the .NET 4.7.1
reference assemblies, all shipped in the tarball for first build time.
The sources of the spec file and the required patch files are
currently maintained on
[https://github.com/tpokorra/mono-5.x-fedora/tree/master/mono-5.18
Github].

We would like to request permission to make a one time exception of
the rule for building mono 5.18.0-1 using monolite and the reference
assemblies, later make mono depend again on itself and rebuild mono
5.18.0-2 using mono-5.18.0-1.

Steps for bootstrapping:

* The Monolite binaries are included in the Mono tarball which is
provided by upstream. See also
http://www.mono-project.com/docs/advanced/monolite/
** Monolite is a minimal binary distribution of mcs. This is the
compiler that is able to build the rest of Mono.
* The binary reference assemblies are included in the Mono tarball
which is provided by upstream. The tarball also includes the sources
of the reference assemblies, which are maintained here:
https://github.com/dotnet/source-build
* In the spec file, we usually delete all dlls and executables before
the build section.
* For the bootstrap, we would once keep the monolite binaries and some
binary reference assemblies.
* In the bootstrap, we rebuild the reference assemblies and include
them in the mono-devel package, as well as the mono compiler.
* After Mono has been built for all primary and secondary
architectures, we enable the deletion of the binaries again in the
spec file.

== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software -
we should have the most recent release of Mono 5.x

It will have the ability to run cross-platform applications that
require compatibility with Microsoft .NET Framework 4.7 and later.

We already have issues upgrading packages like sharpziplib because the
latest upstream version uses new compiler features that are not
included in Mono 4.8 (see
https://bugzilla.redhat.com/show_bug.cgi?id=1601129).

This will also resolve the issues we have because Mono 4.8 does not
build on ppc64 anymore (see
https://bugzilla.redhat.com/show_bug.cgi?id=1588734).

== Scope ==
* Proposal owners:
Update mono spec and build in copr and/or koji until is ready.
Members of the Mono SIG can rebuild their packages with Mono 5, but
tests with keepass for example show that it works fine without
rebuilding even with Mono 5.18. Rebuild of all packages depending on
Mono can happen during the regular mass rebuild.

* Other developers: 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)

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

Tests with keepass without rebuilding keepass worked fine on Mono 5.18.

== How To Test ==
N/A (not a System Wide Change)

== Dependencies ==
This is not a system wide change, but only affects packages depending
on Mono, and should be managed by the members of the [[SIGs/Mono|Mono
SIG]].

Here is a list of packages that require mono-core in Rawhide,
generated with this command: dnf repoquery
--enablerepo=fedora-source --whatrequires mono-core | grep -v
i686

This list even includes packages that are being built from the mono
package (eg. mono-devel and others).


Last metadata expiration check: 0:00:56 ago on Fri Mar  1 23:42:49 2019.
COPASI-0:4.24.197-6.fc30.src
avahi-sharp-0:0.7-18.fc30.x86_64
avahi-ui-sharp-0:0.7-18.fc30.x86_64
banshee-0:2.6.2-32.fc30.x86_64
banshee-community-extensions-0:2.4.0-22.fc30.x86_64
bareftp-0:0.3.12-3.fc30.x86_64
bless-0:0.6.0-26.fc30.x86_64
boo-0:0.9.7.0-11.fc30.x86_64
cdcollect-0:0.6.0-32.fc30.x86_64
dbus-sharp-2:0.8.1-8.fc30.x86_64
dbus-sharp-glib-0:0.6.0-6.fc30.x86_64
gbrainy-1:2.3.5-3.fc30.x86_64
gdata-sharp-0:1.4.0.2-24.fc30.x86_64
gio-sharp-0:0.3-21.fc30.x86_64
gkeyfile-sharp-0:0.1-26.fc30.x86_64
gmime-sharp-0:2.6.23-7.fc30.x86_64
gnome-desktop-sharp-0:2.26.0-35.fc30.x86_64
gnome-do-0:0.95.3-13.fc30.x86_64
gnome-guitar-0:0.8.1-28.fc30.x86_64

[Bug 1685681] New: perl-Coro-Multicore-1.02 is available

[bugzilla]

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

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



Latest upstream release: 1.02
Current version/release in rawhide: 1.01-2.fc30
URL: http://search.cpan.org/dist/Coro-Multicore/

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

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

Re: modular repositories in mock configs: please don't

[stan]

On Tue, 5 Mar 2019 11:18:04 -0500
Neal Gompa  wrote:

> No. It should be possible for modular content to become non-modular
> and vice versa.

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

[Bug 1685531] Upgrade perl-Type-Tie to 0.014

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-Type-Tie-0.014-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-344c45b668

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

[Bug 1685531] Upgrade perl-Type-Tie to 0.014

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Type-Tie-0.014-1.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-418bdaed5f

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

corsepiu pushed to perl-Type-Tie (f29). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2019-03-05 19:10:46 UTC

From 83b3f86b13a0b4b25b78f98c042274fb2990d18a Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Feb 02 2019 01:21:18 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 2c1283b..1d03dd3 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -1,6 +1,6 @@
 Name:   perl-Type-Tie
 Version:0.013
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Tie a variable to a type constraint
 # cf. README
 License:GPL+ or Artistic
@@ -76,6 +76,9 @@ sed -i -e '/^inc\/.*$/d' MANIFEST
 %{_mandir}/man3/*
 
 %changelog
+* Sat Feb 02 2019 Fedora Release Engineering  - 
0.013-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
+
 * Thu Jan 10 2019 Ralf Corsépius  - 0.013-1
 - Upstream update.
 - Add BR: perl(Moo).



https://src.fedoraproject.org/rpms/perl-Type-Tie/c/83b3f86b13a0b4b25b78f98c042274fb2990d18a?branch=f29
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

corsepiu pushed to perl-Type-Tie (f29). "Upstream update."

[notifications]

Notification time stamped 2019-03-05 19:10:46 UTC

From 81c7a548106baf7d5e6c17673c83a1988127d817 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Mar 05 2019 19:07:56 +
Subject: Upstream update.


---

diff --git a/.gitignore b/.gitignore
index 336d57b..6bf852e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Type-Tie-0.013.tar.gz
+/Type-Tie-0.014.tar.gz
diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 1d03dd3..0fbc6cf 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -1,6 +1,6 @@
 Name:   perl-Type-Tie
-Version:0.013
-Release:2%{?dist}
+Version:0.014
+Release:1%{?dist}
 Summary:Tie a variable to a type constraint
 # cf. README
 License:GPL+ or Artistic
@@ -76,6 +76,9 @@ sed -i -e '/^inc\/.*$/d' MANIFEST
 %{_mandir}/man3/*
 
 %changelog
+* Tue Mar 05 2019 Ralf Corsépius  - 0.014-1
+- Upstream update.
+
 * Sat Feb 02 2019 Fedora Release Engineering  - 
0.013-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 
diff --git a/sources b/sources
index 9d92a67..fbf7082 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Type-Tie-0.013.tar.gz) = 
79a2a7441bcd391d393302e88d76283f616119f9e53e2c98ad980d9681e41fae2c329f6165d398b3cdc51f07a2746e39966b84d5521eb996bf471b0ba78c0d42
+SHA512 (Type-Tie-0.014.tar.gz) = 
c7952792ea4cd365db28d940945adb295134f2780495700620afd9b0fff0fb619a8589ccd3b5ed0af6b56ad6d9c4589b2ab61605890e897cc1ff7010c5e3bad1



https://src.fedoraproject.org/rpms/perl-Type-Tie/c/81c7a548106baf7d5e6c17673c83a1988127d817?branch=f29
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

corsepiu pushed to perl-Type-Tie (f30). "Upstream update."

[notifications]

Notification time stamped 2019-03-05 19:09:08 UTC

From 81c7a548106baf7d5e6c17673c83a1988127d817 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Mar 05 2019 19:07:56 +
Subject: Upstream update.


---

diff --git a/.gitignore b/.gitignore
index 336d57b..6bf852e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Type-Tie-0.013.tar.gz
+/Type-Tie-0.014.tar.gz
diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 1d03dd3..0fbc6cf 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -1,6 +1,6 @@
 Name:   perl-Type-Tie
-Version:0.013
-Release:2%{?dist}
+Version:0.014
+Release:1%{?dist}
 Summary:Tie a variable to a type constraint
 # cf. README
 License:GPL+ or Artistic
@@ -76,6 +76,9 @@ sed -i -e '/^inc\/.*$/d' MANIFEST
 %{_mandir}/man3/*
 
 %changelog
+* Tue Mar 05 2019 Ralf Corsépius  - 0.014-1
+- Upstream update.
+
 * Sat Feb 02 2019 Fedora Release Engineering  - 
0.013-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 
diff --git a/sources b/sources
index 9d92a67..fbf7082 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Type-Tie-0.013.tar.gz) = 
79a2a7441bcd391d393302e88d76283f616119f9e53e2c98ad980d9681e41fae2c329f6165d398b3cdc51f07a2746e39966b84d5521eb996bf471b0ba78c0d42
+SHA512 (Type-Tie-0.014.tar.gz) = 
c7952792ea4cd365db28d940945adb295134f2780495700620afd9b0fff0fb619a8589ccd3b5ed0af6b56ad6d9c4589b2ab61605890e897cc1ff7010c5e3bad1



https://src.fedoraproject.org/rpms/perl-Type-Tie/c/81c7a548106baf7d5e6c17673c83a1988127d817?branch=f30
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

corsepiu pushed to perl-Type-Tie (master). "Upstream update."

[notifications]

Notification time stamped 2019-03-05 19:08:06 UTC

From 81c7a548106baf7d5e6c17673c83a1988127d817 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Mar 05 2019 19:07:56 +
Subject: Upstream update.


---

diff --git a/.gitignore b/.gitignore
index 336d57b..6bf852e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Type-Tie-0.013.tar.gz
+/Type-Tie-0.014.tar.gz
diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 1d03dd3..0fbc6cf 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -1,6 +1,6 @@
 Name:   perl-Type-Tie
-Version:0.013
-Release:2%{?dist}
+Version:0.014
+Release:1%{?dist}
 Summary:Tie a variable to a type constraint
 # cf. README
 License:GPL+ or Artistic
@@ -76,6 +76,9 @@ sed -i -e '/^inc\/.*$/d' MANIFEST
 %{_mandir}/man3/*
 
 %changelog
+* Tue Mar 05 2019 Ralf Corsépius  - 0.014-1
+- Upstream update.
+
 * Sat Feb 02 2019 Fedora Release Engineering  - 
0.013-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 
diff --git a/sources b/sources
index 9d92a67..fbf7082 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Type-Tie-0.013.tar.gz) = 
79a2a7441bcd391d393302e88d76283f616119f9e53e2c98ad980d9681e41fae2c329f6165d398b3cdc51f07a2746e39966b84d5521eb996bf471b0ba78c0d42
+SHA512 (Type-Tie-0.014.tar.gz) = 
c7952792ea4cd365db28d940945adb295134f2780495700620afd9b0fff0fb619a8589ccd3b5ed0af6b56ad6d9c4589b2ab61605890e897cc1ff7010c5e3bad1



https://src.fedoraproject.org/rpms/perl-Type-Tie/c/81c7a548106baf7d5e6c17673c83a1988127d817?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Miroslav Suchý]

Dne 04. 03. 19 v 17:34 Ken Dreyer napsal(a):
> 
> I'm there with you Richard. I don't really get how I can get started building 
> a module outside of the Fedora
> infrastructure's system (Koji or Copr).

In fact, Copr support building modules for ages - even before the modularity 
has been finalized.

You just create project in Copr, build regular packages there. Then you click 
on "Modules" tab, then "Create new
module", select which packages should be part of module and submit the form. 
Few seconds later your module should be ready.

Copr does not support all features of modularity, because the format of modules 
changed every few week and it was hard
for us to keep pace. But you are simply build simple module in Copr.

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

Call for maintainers of Scotch package (bz#1680315)

[Antonio Trande]

Hello.

Please, take a look to this issue
https://bugzilla.redhat.com/show_bug.cgi?id=1680315

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



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

Fedora Rawhide-20190205.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
6 of 47 required tests failed, 3 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 18/132 (x86_64), 1/2 (arm), 1/24 (i386)

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

ID: 350537  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/350537
ID: 350538  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/350538
ID: 350846  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/350846

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

ID: 350507  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/350507
ID: 350508  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/350508
ID: 350510  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/350510
ID: 350511  Test: x86_64 Server-dvd-iso server_cockpit_default **GATING**
URL: https://openqa.fedoraproject.org/tests/350511
ID: 350513  Test: x86_64 Server-dvd-iso server_firewall_default **GATING**
URL: https://openqa.fedoraproject.org/tests/350513
ID: 350522  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/350522
ID: 350523  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/350523
ID: 350565  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/350565
ID: 350571  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/350571
ID: 350585  Test: x86_64 universal install_kickstart_firewall_configured 
**GATING**
URL: https://openqa.fedoraproject.org/tests/350585
ID: 350591  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/350591
ID: 350592  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/350592
ID: 350618  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/350618
ID: 350632  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/350632
ID: 350639  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/350639
ID: 350656  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/350656
ID: 358561  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/358561

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

New soft failures (same test not soft failed in Rawhide-20190204.n.0):

ID: 350546  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/350546
ID: 350570  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/350570
ID: 350847  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/350847

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

ID: 350526  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/350526
ID: 350527  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/350527
ID: 350545  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/350545
ID: 350550  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/350550
ID: 350648  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/350648

Passed openQA tests: 104/132 (x86_64), 19/24 (i386)

New passes (same test not passed in Rawhide-20190204.n.0):

ID: 350531  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/350531
ID: 350534  Test: x86_64 Workstation-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/350534
ID: 350539  Test: x86_64 Workstation-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/350539
ID: 350540  Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/350540
ID: 350541  Test: x86_64 Workstation-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/350541
ID: 350542  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/350542
ID: 350543  Test: x86_64 Workstation-live-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/350543
ID: 350548  

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

[smooge]

Dear all,

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

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


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

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

Re: [HEADS UP] Minetest 5.0.0

[Samuel Sieb]

On 3/5/19 8:28 AM, Igor Gnatenko wrote:
I've prepared PR for new version of minetest: 
https://src.fedoraproject.org/rpms/minetest/pull-request/3


Thank you.

I'll merge it later this week and build for F30 and F31. It also 
involves License change but it was just incorrect even before.


I'll also probably make a module out of it so it would be available in 
F28/F29 too.


See changelog here: 
https://dev.minetest.net/Changelog#0.4.16_.E2.86.92_5.0.0


One important point is that they changed major versions because there 
are some not backwards-compatible changes.  You can't connect to a 
version 5 server with an older client.


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

Re: Donate 1 minute of your time to test upgrades from F29 to F30

[mastaiza wufam]

sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30
--enablerepo=updates-testing distro-sync
Copr repo for bumblebee owned by chenxiaolong   126  B/s | 341  B
 00:02
Не удается синхронизировать кэш для репозитория «chenxiaolong-bumblebee»
Copr repo for flat-remix owned by daniruiz  177  B/s | 341  B
 00:01
Не удается синхронизировать кэш для репозитория «daniruiz-flat-remix»
Copr repo for Riot owned by taw 176  B/s | 341  B
 00:01
Не удается синхронизировать кэш для репозитория «taw-Riot»
Fedora 30 openh264 (From Cisco) - x86_64151  B/s | 543  B
 00:03
Fedora 30 openh264 (From Cisco) - x86_641.6 MB/s | 1.6 kB
 00:00
Импорт GPG-ключа 0xCFC659B9:
Идентификатор пользователя:  "Fedora (30) <
fedora-30-prim...@fedoraproject.org>"
Отпечаток: F1D8 EC98 F241 AAF2 0DF6 9420 EF3C 111F CFC6 59B9
Источник:  /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-30-x86_64
Продолжить? [д/Н]: y
Fedora 30 openh264 (From Cisco) - x86_64976  B/s | 5.1 kB
 00:05
Fedora Modular 30 - x86_64  491 kB/s | 2.4 MB
 00:04
negativo17 - Multimedia 1.9 kB/s | 2.6 kB
 00:01
Не удается синхронизировать кэш для репозитория «fedora-multimedia»
negativo17 - Nvidia  41 kB/s | 115 kB
 00:02
Fedora Modular 30 - x86_64 - Updates 62  B/s | 257  B
 00:04
Fedora 30 - x86_64 - Test Updates69  B/s | 257  B
 00:03
Fedora 30 - x86_64 - Updates 68  B/s | 257  B
 00:03
Fedora 30 - x86_64  3.3 MB/s |  61 MB
 00:18
RPM Fusion for Fedora 30 - Free tainted  47 kB/s |  71 kB
 00:01
Не удается синхронизировать кэш для репозитория «rpmfusion-free-tainted»
RPM Fusion for Fedora 30 - Free - Updates46 kB/s |  71 kB
 00:01
Не удается синхронизировать кэш для репозитория «rpmfusion-free-updates»
RPM Fusion for Fedora 30 - Free  46 kB/s |  71 kB
 00:01
Не удается синхронизировать кэш для репозитория «rpmfusion-free»
RPM Fusion for Fedora 30 - Nonfree - NVIDIA Dri  46 kB/s |  71 kB
 00:01
Не удается синхронизировать кэш для репозитория
«rpmfusion-nonfree-nvidia-driver»
RPM Fusion for Fedora 30 - Nonfree tainted   46 kB/s |  71 kB
 00:01
Не удается синхронизировать кэш для репозитория «rpmfusion-nonfree-tainted»
RPM Fusion for Fedora 30 - Nonfree - Updates 47 kB/s |  71 kB
 00:01
Не удается синхронизировать кэш для репозитория «rpmfusion-nonfree-updates»
RPM Fusion for Fedora 30 - Nonfree   46 kB/s |  71 kB
 00:01
Не удается синхронизировать кэш для репозитория «rpmfusion-nonfree»
RPM Sphere - Basearch   1.1 kB/s | 3.0 kB
 00:02
RPM Sphere - Noarch 1.1 kB/s | 3.0 kB
 00:02
Russian Fedora for Fedora 30 - Free - Updates70  B/s |  81  B
 00:01
Не удается синхронизировать кэш для репозитория «russianfedora-free-updates»
Russian Fedora for Fedora 30 - Free  55  B/s |  64  B
 00:01
Не удается синхронизировать кэш для репозитория «russianfedora-free»
Russian Fedora for Fedora 30 - Nonfree - Update  72  B/s |  84  B
 00:01
Не удается синхронизировать кэш для репозитория
«russianfedora-nonfree-updates»
Russian Fedora for Fedora 30 - Nonfree   58  B/s |  67  B
 00:01
Не удается синхронизировать кэш для репозитория «russianfedora-nonfree»
Ignoring repositories: chenxiaolong-bumblebee, daniruiz-flat-remix,
taw-Riot, fedora-multimedia, rpmfusion-free-tainted,
rpmfusion-free-updates, rpmfusion-free, rpmfusion-nonfree-nvidia-driver,
rpmfusion-nonfree-tainted, rpmfusion-nonfree-updates, rpmfusion-nonfree,
russianfedora-free-updates, russianfedora-free,
russianfedora-nonfree-updates, russianfedora-nonfree
Ошибка:
 Проблема 1: problem with installed package klavaro-3.03-6.fc29.x86_64
  - klavaro-3.03-6.fc29.x86_64 does not belong to a distupgrade repository
  - nothing provides libgtkdataboks.so.0()(64bit) needed by
klavaro-3.04-1.fc30.x86_64
 Проблема 2: package compat-ffmpeg-libs-1:3.4.5-2.fc29.x86_64 requires
libtesseract.so.3()(64bit), but none of the providers can be installed
  - tesseract-3.05.02-1.fc29.x86_64 does not belong to a distupgrade
repository
  - problem with installed package compat-ffmpeg-libs-1:3.4.5-2.fc29.x86_64
 Проблема 3: package guvcview-2.0.6-1.fc29.x86_64 requires
libavcodec.so.58()(64bit), but none of the providers can be installed
  - package guvcview-2.0.6-1.fc29.x86_64 requires
libavcodec.so.58(LIBAVCODEC_58)(64bit), but none of the providers can be
installed
  - package guvcview-2.0.6-1.fc29.x86_64 requires libavutil.so.56()(64bit),
but none of the providers can be installed
  - package guvcview-2.0.6-1.fc29.x86_64 requires
libavutil.so.56(LIBAVUTIL_56)(64bit), but none of the providers can be
installed
  - ffmpeg-libs-1:4.1.1-1.fc29.x86_64 does not belong to a distupgrade
repository
  - problem with installed package guvcview-2.0.6-1.fc29.x86_64
 Проблема 4: package mpv-1:0.29.1-4.fc29.x86_64 requires
libavdevice.so.58()(64bit), but none of 

[HEADS UP] Minetest 5.0.0

[Igor Gnatenko]

Hello folks,

I've prepared PR for new version of minetest:
https://src.fedoraproject.org/rpms/minetest/pull-request/3

I'll merge it later this week and build for F30 and F31. It also involves
License change but it was just incorrect even before.

I'll also probably make a module out of it so it would be available in
F28/F29 too.

See changelog here:
https://dev.minetest.net/Changelog#0.4.16_.E2.86.92_5.0.0

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

Re: modular repositories in mock configs: please don't

[Neal Gompa]

On Tue, Mar 5, 2019 at 11:01 AM stan  wrote:
>
> On Tue, 5 Mar 2019 09:08:19 +0100
> Adam Samalik  wrote:
>
> > On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth 
> > wrote:
>
> > > Why should I care? Please, win me over. (I'm being serious.)
> > >
> >
> > I think you should care if:
> >
> > a) You need to maintain multiple versions of the same app/runtime/set
> > of tools tools in Fedora (or an alternative to something that already
> > exists), or
> > b) You only want to maintain one source branch per package for all
> > Fedora releases, or
> > c) You could benefit from having a build recipe in case you maintain
> > app/runtime/set of tools tools represented by multiple packages that
> > need to be built in the right order
> >
> > But if any of the above is something that you need/want to do, then
> > Modularity won't help you nor hurt you in any way.
> >
> >
> > > I view the current RPM system as reliable, standard, and
> > > well-documented. It's
> > > served me and the people I know that use it well for decades. I view
> > > Modularity as
> > > an answer to a question no one asked. It presents new problems that
> > > never existed
> > > and has been somewhat silently taking over RPM-land with very little
> > > community
> > > involvement.
>
> I'm not a packager, I only follow devel to see what is coming down
> the pipe as a user.  I'm concerned about modularity.  Like Michael, I
> find rpm works fine for my use case, an individual workstation.  I have
> a couple of comments, but since I am not the target of modularity, take
> them as curiosity.
>
> It seems that modularity will create one more layer of indirection, so
> security holes will be more prone to exist and be harder to find and
> fix for the user, particularly on mixed rpm / modularity systems.
>

Modules are merely collections of rpms built in a special way.
Sometimes that's with macro definitions to force overrides for
specific configurations, and sometimes that's with filtering packages,
or customizing build and runtime content.

> Modularity seems to be a workaround to avoid making the system fully
> multi version.  Admittedly, that is a lot of work, gcc has to be
> modified to create a dictionary of libraries and api calls needed in
> executables, libraries have to be modified to publish their api calls,
> the kernel has to sort through multiple versions of a binary checking
> priorities (somehow).  rpm has to be modified to allow multiple version
> installation, and to do library checking to be sure that an existing
> library will cover needed calls. There has to be garbage collection for
> libraries no longer needed by executables on the system.  etc.  The up
> side is there is no more shared library so numbers for libraries, so
> updates will *always* succeed, and the garbage collector will take
> care of no longer needed packages. Is the following a good summarization
> of the purpose of modularity? Modularity is a workaround using the
> pareto principle to get 80% of the benefits of multi version with only
> 20% of the work.
>

RPM already allows multiversion installation with the caveat that
there are no file collisions. The other aspects are things that can be
handled by DNF. Modules are only about some of those use cases. The
other major cases involve build-time customization and partitioning
built packages into supportable or non-supportable groups.

> Would it be practical to have a new hierarchy under /usr for
> modularity, say /usr/mod, or move the current /usr to /usr/rpm and
> let /usr be for modularity?  This would make it easier to specify which
> version of a binary to run, and which should be default in the path.
> So, if I install a module with old, possibly insecure components,
> because I need it for legacy purposes, I can specify it in a script, and
> let the newer version be the default for general use.

No. It should be possible for modular content to become non-modular
and vice versa.



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

Re: modular repositories in mock configs: please don't

[stan]

On Tue, 5 Mar 2019 09:08:19 +0100
Adam Samalik  wrote:

> On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth 
> wrote:

> > Why should I care? Please, win me over. (I'm being serious.)
> >  
> 
> I think you should care if:
> 
> a) You need to maintain multiple versions of the same app/runtime/set
> of tools tools in Fedora (or an alternative to something that already
> exists), or
> b) You only want to maintain one source branch per package for all
> Fedora releases, or
> c) You could benefit from having a build recipe in case you maintain
> app/runtime/set of tools tools represented by multiple packages that
> need to be built in the right order
> 
> But if any of the above is something that you need/want to do, then
> Modularity won't help you nor hurt you in any way.
> 
> 
> > I view the current RPM system as reliable, standard, and
> > well-documented. It's
> > served me and the people I know that use it well for decades. I view
> > Modularity as
> > an answer to a question no one asked. It presents new problems that
> > never existed
> > and has been somewhat silently taking over RPM-land with very little
> > community
> > involvement.

I'm not a packager, I only follow devel to see what is coming down
the pipe as a user.  I'm concerned about modularity.  Like Michael, I
find rpm works fine for my use case, an individual workstation.  I have
a couple of comments, but since I am not the target of modularity, take
them as curiosity.

It seems that modularity will create one more layer of indirection, so
security holes will be more prone to exist and be harder to find and
fix for the user, particularly on mixed rpm / modularity systems.

Modularity seems to be a workaround to avoid making the system fully
multi version.  Admittedly, that is a lot of work, gcc has to be
modified to create a dictionary of libraries and api calls needed in
executables, libraries have to be modified to publish their api calls,
the kernel has to sort through multiple versions of a binary checking
priorities (somehow).  rpm has to be modified to allow multiple version
installation, and to do library checking to be sure that an existing
library will cover needed calls. There has to be garbage collection for
libraries no longer needed by executables on the system.  etc.  The up
side is there is no more shared library so numbers for libraries, so
updates will *always* succeed, and the garbage collector will take
care of no longer needed packages. Is the following a good summarization
of the purpose of modularity? Modularity is a workaround using the
pareto principle to get 80% of the benefits of multi version with only
20% of the work.

Would it be practical to have a new hierarchy under /usr for
modularity, say /usr/mod, or move the current /usr to /usr/rpm and
let /usr be for modularity?  This would make it easier to specify which
version of a binary to run, and which should be default in the path.
So, if I install a module with old, possibly insecure components,
because I need it for legacy purposes, I can specify it in a script, and
let the newer version be the default for general use.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Adam Williamson]

On Tue, 2019-03-05 at 14:20 +, Christophe de Dinechin wrote:
> Note sure if you care about this test from F28, but this is a heavily loaded 
> machine where I never find the time to upgrade. Just in case it's of any use:
> 
> sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 
> --enablerepo=updates-testing distro-sync
> Main config did not have a module_platform_id attr. before setopt
> Main config did not have a module_platform_id attr. before setopt
> Fedora 30 - x86_64 - Test Updates   706  B/s | 257  B 00:00   
>  
> Fedora 30 - x86_64 - Updates657  B/s | 257  B 00:00   
>  
> Fedora 30 - x86_64  721 kB/s |  61 MB 01:26   
>  
> Failed to synchronize cache for repo 'docker-ce-stable', disabling.
> Failed to synchronize cache for repo 'fedora-multimedia', disabling.
> Failed to synchronize cache for repo 'rpmfusion-free-updates', disabling.
> Failed to synchronize cache for repo 'rpmfusion-free', disabling.
> Failed to synchronize cache for repo 'rpmfusion-nonfree-updates', disabling.
> Failed to synchronize cache for repo 'rpmfusion-nonfree', disabling.
> Failed to synchronize cache for repo 'zfs', disabling.
> Last metadata expiration check: 0:00:00 ago on Tue 05 Mar 2019 03:11:31 PM 
> CET.
> Error: 
>  Problem 1: package compat-ffmpeg-libs-1:3.4.5-2.fc28.x86_64 requires 
> libass.so.5()(64bit), but none of the providers can be installed
>   - libass-0.13.4-6.fc28.x86_64 does not belong to a distupgrade repository
>   - problem with installed package compat-ffmpeg-libs-1:3.4.5-2.fc28.x86_64
>  Problem 2: package ffmpeg-libs-1:4.1.1-1.fc28.x86_64 requires 
> libtesseract.so.3()(64bit), but none of the providers can be installed
>   - tesseract-3.05.02-1.fc28.x86_64 does not belong to a distupgrade 
> repository
>   - problem with installed package ffmpeg-libs-1:4.1.1-1.fc28.x86_64
>  Problem 3: package rpmfusion-free-release-28-1.noarch requires 
> system-release(28), but none of the providers can be installed
>   - fedora-release-28-6.noarch does not belong to a distupgrade repository
>   - problem with installed package rpmfusion-free-release-28-1.noarch
>  Problem 4: package vlc-1:3.0.6-1.fc28.x86_64 requires 
> libplacebo.so.4()(64bit), but none of the providers can be installed
>   - libplacebo-0.4.0-1.fc28.x86_64 does not belong to a distupgrade repository
>   - problem with installed package vlc-1:3.0.6-1.fc28.x86_64
>  Problem 5: package fedora-release-28-6.noarch requires fedora-repos(28) >= 
> 1, but none of the providers can be installed
>   - package rpmfusion-nonfree-release-28-1.noarch requires 
> system-release(28), but none of the providers can be installed
>   - fedora-repos-28-5.noarch does not belong to a distupgrade repository
>   - problem with installed package rpmfusion-nonfree-release-28-1.noarch
>  Problem 6: package vlc-1:3.0.6-1.fc28.x86_64 requires libixml.so.2()(64bit), 
> but none of the providers can be installed
>   - package vlc-devel-1:3.0.6-1.fc28.x86_64 requires libvlc.so.5()(64bit), 
> but none of the providers can be installed
>   - libupnp-1.6.25-1.fc28.x86_64 does not belong to a distupgrade repository
>   - problem with installed package vlc-devel-1:3.0.6-1.fc28.x86_64
>  Problem 7: package ffmpeg-libs-1:4.1.1-1.fc28.x86_64 requires 
> libtesseract.so.3()(64bit), but none of the providers can be installed
>   - package tesseract-3.05.02-1.fc28.x86_64 requires 
> libicudata.so.60()(64bit), but none of the providers can be installed
>   - package ffmpeg-1:4.1.1-1.fc28.x86_64 requires ffmpeg-libs(x86-64) = 
> 1:4.1.1-1.fc28, but none of the providers can be installed
>   - libicu-60.2-2.fc28.x86_64 does not belong to a distupgrade repository
>   - problem with installed package ffmpeg-1:4.1.1-1.fc28.x86_64
>  Problem 8: cannot install both tesseract-4.0.0-3.fc30.x86_64 and 
> tesseract-3.05.02-1.fc28.x86_64
>   - package opencv-contrib-3.4.4-5.fc30.x86_64 requires 
> libtesseract.so.4()(64bit), but none of the providers can be installed
>   - package compat-ffmpeg-libs-1:3.4.5-2.fc28.x86_64 requires 
> libtesseract.so.3()(64bit), but none of the providers can be installed
>   - package gstreamer1-plugins-bad-1:1.14.1-7.fc28.x86_64 requires 
> libopencv_aruco.so.3.4()(64bit), but none of the providers can be installed
>   - package gstreamer1-libav-1:1.14.1-1.fc28.x86_64 requires 
> libavcodec.so.57()(64bit), but none of the providers can be installed
>   - opencv-contrib-3.4.1-3.fc28.x86_64 does not belong to a distupgrade 
> repository
>   - problem with installed package 
> gstreamer1-plugins-bad-1:1.14.1-7.fc28.x86_64
>   - problem with installed package gstreamer1-libav-1:1.14.1-1.fc28.x86_64
>  Problem 9: cannot install both libicu-63.1-2.fc30.x86_64 and 
> libicu-60.2-2.fc28.x86_64
>   - package tesseract-3.05.02-1.fc28.x86_64 requires 
> libicudata.so.60()(64bit), but none of the providers can be installed
>   - package boost-graph-1.69.0-6.fc30.x86_64 requires 
> 

[Bug 1684104] Upgrade perl-Mail-IMAPClient to 3.42

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2019-03-05 15:04:42



--- Comment #1 from Tom "spot" Callaway  ---
3.42 in fc30+.

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

[Bug 1684273] perl-Date-Manip-6.76 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 1684855] perl-CPAN-2.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Christophe de Dinechin]

Note sure if you care about this test from F28, but this is a heavily loaded 
machine where I never find the time to upgrade. Just in case it's of any use:

sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 
--enablerepo=updates-testing distro-sync
Main config did not have a module_platform_id attr. before setopt
Main config did not have a module_platform_id attr. before setopt
Fedora 30 - x86_64 - Test Updates   706  B/s | 257  B 00:00
Fedora 30 - x86_64 - Updates657  B/s | 257  B 00:00
Fedora 30 - x86_64  721 kB/s |  61 MB 01:26
Failed to synchronize cache for repo 'docker-ce-stable', disabling.
Failed to synchronize cache for repo 'fedora-multimedia', disabling.
Failed to synchronize cache for repo 'rpmfusion-free-updates', disabling.
Failed to synchronize cache for repo 'rpmfusion-free', disabling.
Failed to synchronize cache for repo 'rpmfusion-nonfree-updates', disabling.
Failed to synchronize cache for repo 'rpmfusion-nonfree', disabling.
Failed to synchronize cache for repo 'zfs', disabling.
Last metadata expiration check: 0:00:00 ago on Tue 05 Mar 2019 03:11:31 PM CET.
Error: 
 Problem 1: package compat-ffmpeg-libs-1:3.4.5-2.fc28.x86_64 requires 
libass.so.5()(64bit), but none of the providers can be installed
  - libass-0.13.4-6.fc28.x86_64 does not belong to a distupgrade repository
  - problem with installed package compat-ffmpeg-libs-1:3.4.5-2.fc28.x86_64
 Problem 2: package ffmpeg-libs-1:4.1.1-1.fc28.x86_64 requires 
libtesseract.so.3()(64bit), but none of the providers can be installed
  - tesseract-3.05.02-1.fc28.x86_64 does not belong to a distupgrade repository
  - problem with installed package ffmpeg-libs-1:4.1.1-1.fc28.x86_64
 Problem 3: package rpmfusion-free-release-28-1.noarch requires 
system-release(28), but none of the providers can be installed
  - fedora-release-28-6.noarch does not belong to a distupgrade repository
  - problem with installed package rpmfusion-free-release-28-1.noarch
 Problem 4: package vlc-1:3.0.6-1.fc28.x86_64 requires 
libplacebo.so.4()(64bit), but none of the providers can be installed
  - libplacebo-0.4.0-1.fc28.x86_64 does not belong to a distupgrade repository
  - problem with installed package vlc-1:3.0.6-1.fc28.x86_64
 Problem 5: package fedora-release-28-6.noarch requires fedora-repos(28) >= 1, 
but none of the providers can be installed
  - package rpmfusion-nonfree-release-28-1.noarch requires system-release(28), 
but none of the providers can be installed
  - fedora-repos-28-5.noarch does not belong to a distupgrade repository
  - problem with installed package rpmfusion-nonfree-release-28-1.noarch
 Problem 6: package vlc-1:3.0.6-1.fc28.x86_64 requires libixml.so.2()(64bit), 
but none of the providers can be installed
  - package vlc-devel-1:3.0.6-1.fc28.x86_64 requires libvlc.so.5()(64bit), but 
none of the providers can be installed
  - libupnp-1.6.25-1.fc28.x86_64 does not belong to a distupgrade repository
  - problem with installed package vlc-devel-1:3.0.6-1.fc28.x86_64
 Problem 7: package ffmpeg-libs-1:4.1.1-1.fc28.x86_64 requires 
libtesseract.so.3()(64bit), but none of the providers can be installed
  - package tesseract-3.05.02-1.fc28.x86_64 requires libicudata.so.60()(64bit), 
but none of the providers can be installed
  - package ffmpeg-1:4.1.1-1.fc28.x86_64 requires ffmpeg-libs(x86-64) = 
1:4.1.1-1.fc28, but none of the providers can be installed
  - libicu-60.2-2.fc28.x86_64 does not belong to a distupgrade repository
  - problem with installed package ffmpeg-1:4.1.1-1.fc28.x86_64
 Problem 8: cannot install both tesseract-4.0.0-3.fc30.x86_64 and 
tesseract-3.05.02-1.fc28.x86_64
  - package opencv-contrib-3.4.4-5.fc30.x86_64 requires 
libtesseract.so.4()(64bit), but none of the providers can be installed
  - package compat-ffmpeg-libs-1:3.4.5-2.fc28.x86_64 requires 
libtesseract.so.3()(64bit), but none of the providers can be installed
  - package gstreamer1-plugins-bad-1:1.14.1-7.fc28.x86_64 requires 
libopencv_aruco.so.3.4()(64bit), but none of the providers can be installed
  - package gstreamer1-libav-1:1.14.1-1.fc28.x86_64 requires 
libavcodec.so.57()(64bit), but none of the providers can be installed
  - opencv-contrib-3.4.1-3.fc28.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package gstreamer1-plugins-bad-1:1.14.1-7.fc28.x86_64
  - problem with installed package gstreamer1-libav-1:1.14.1-1.fc28.x86_64
 Problem 9: cannot install both libicu-63.1-2.fc30.x86_64 and 
libicu-60.2-2.fc28.x86_64
  - package tesseract-3.05.02-1.fc28.x86_64 requires libicudata.so.60()(64bit), 
but none of the providers can be installed
  - package boost-graph-1.69.0-6.fc30.x86_64 requires libicuuc.so.63()(64bit), 
but none of the providers can be installed
  - package ffmpeg-libs-1:4.1.1-1.fc28.x86_64 requires 
libtesseract.so.3()(64bit), but none of the providers can be installed
  - problem with installed package 

Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Christophe de Dinechin]

# sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 
--enablerepo=updates-testing distro-sync
Fedora Modular 30 - x86_64  187 kB/s | 2.4 MB 00:12
Fedora Modular 30 - x86_64 - Updates 35  B/s | 257  B 00:07
Fedora 30 - x86_64 - Test Updates36  B/s | 257  B 00:07
Fedora 30 - x86_64 - Updates 40  B/s | 257  B 00:06
Fedora 30 - x86_64  429 kB/s |  61 MB 02:26
RCM Tools for Fedora 30 (RPMs)  0.0  B/s |   0  B 00:01
Failed to synchronize cache for repo 'rcm-tools-fedora-rpms'
RPM Fusion for Fedora 30 - Free - Updates24 kB/s |  71 kB 00:02
Failed to synchronize cache for repo 'rpmfusion-free-updates'
RPM Fusion for Fedora 30 - Free  32 kB/s |  71 kB 00:02
Failed to synchronize cache for repo 'rpmfusion-free'
RPM Fusion for Fedora 30 - Nonfree - Updates 25 kB/s |  71 kB 00:02
Failed to synchronize cache for repo 'rpmfusion-nonfree-updates'
RPM Fusion for Fedora 30 - Nonfree   19 kB/s |  71 kB 00:03
Failed to synchronize cache for repo 'rpmfusion-nonfree'
Ignoring repositories: rcm-tools-fedora-rpms, rpmfusion-free-updates, 
rpmfusion-free, rpmfusion-nonfree-updates, rpmfusion-nonfree
Error: 
Problem 1: package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = 
1.57-6.fc29, but none of the providers can be installed
 - rpkg-common-1.57-6.fc29.noarch does not belong to a distupgrade repository
 - problem with installed package python2-rpkg-1.57-6.fc29.noarch
Problem 2: package rpmfusion-free-release-29-1.noarch requires 
system-release(29), but none of the providers can be installed
 - fedora-release-29-7.noarch does not belong to a distupgrade repository
 - problem with installed package rpmfusion-free-release-29-1.noarch
Problem 3: package vlc-core-1:3.0.6-16.fc29.x86_64 requires 
libprotobuf-lite.so.15()(64bit), but none of the providers can be installed
 - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade repository
 - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64
Problem 4: package fedora-release-29-7.noarch requires fedora-repos(29) >= 1, 
but none of the providers can be installed
 - package rpmfusion-nonfree-release-29-1.noarch requires system-release(29), 
but none of the providers can be installed
 - fedora-repos-29-3.noarch does not belong to a distupgrade repository
 - problem with installed package rpmfusion-nonfree-release-29-1.noarch
Problem 5: cannot install both rpkg-common-1.57-6.fc30.noarch and 
rpkg-common-1.57-6.fc29.noarch
 - package python3-rpkg-1.57-6.fc30.noarch requires rpkg-common = 1.57-6.fc30, 
but none of the providers can be installed
 - package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = 1.57-6.fc29, 
but none of the providers can be installed
 - problem with installed package python3-rpkg-1.57-6.fc29.noarch
 - package rhpkg-1.35-7.fc28eng.noarch requires python2-rpkg >= 1.57, but none 
of the providers can be installed
 - python3-rpkg-1.57-6.fc29.noarch does not belong to a distupgrade repository
 - problem with installed package rhpkg-1.35-7.fc28eng.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

The state of Zanata Python client (Python 3 support)

[Martin Kolman]

Hi,
I come from the tha Anaconda installer project and we use the Python Zanata 
client to push & pull translations from the
Fedora Zanata instance where Anaconda is being translated. As far as I know, 
there are many other projects that do the
same (Blivet, Blivet-GUI, Storaged, etc.), even though it might not be readily 
apparent due to not directly depending on
the python2-zanata-client package, but rather just installing it manually on 
the machine where builds are being created.

As we all know, Python 2 is going away soon (in less than 10 months) and Fedora 
is already doing a lot of work to get
remove as many Python 2 packages as possible. 

Therefore it's pretty alarming that something as important as a client for the 
official Fedora translation service is
still Python 2-only with not even a hint of Python 3 support being worked on as 
far as I can tell. Python Zanata client
upstream[0] has last activity ~year ago, but seems to be mostly dead since 2017 
with no support for Python 3 in sight.

There are also some bugs & an upstream issue inquiring about Python 3 support 
in the Zanata Python client:
https://bugzilla.redhat.com/show_bug.cgi?id=1676408
https://bugzilla.redhat.com/show_bug.cgi?id=1685550
https://zanata.atlassian.net/browse/ZNTA-2791

And at the moment, the client can't even be installed on Rawhide and F30:
https://bugzilla.redhat.com/show_bug.cgi?id=1676388

This has prompted me to write this email & to CC all people mentioned as 
maintainers on the package page[0].

What can be done about this ? Is Python 3 support for the Zanata Python client 
being worked on, so that we won't loose
the package ? Or do we just wait for it to be dropped from Fedora - and then 
what ?

Hopefully someone can answer these questions. :)

Best Wishes
Martin Kolman

[0] https://github.com/zanata/zanata-python-client
[1] https://src.fedoraproject.org/rpms/zanata-python-client
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30 Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 30 schedule[1], with several
significant cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 30
packages must be submitted to
updates-testing and pass the relevant requirements[3] before they will be
marked as 'stable' and moved to the
fedora repository.

Today is also the Beta freeze[4]. This means that only packages which fix
accepted blocker or freeze exception
bugs[5][6] will be marked as 'stable' and included in the Beta composes.
Other builds will remain in updates-
testing until the Beta release is approved, at which point the Beta freeze
is lifted and packages can move to
'stable' as usual until the Final freeze.

Finally, today is the '100% code complete deadline' Change Checkpoint[5],
meaning that Fedora 30 Changes
must now be code complete, meaning all the code required to enable to the
new change is finished. The level
of code completeness is reflected as tracker bug state ON_QA. The change
does not have to be fully tested
by this deadline'.

Finally, today is also the Software String freeze[7], which means that
strings marked for translation in Fedora-
translated projects should not now be changed for Fedora 30.

Mohan Boddu

[1] https://fedoraproject.org/wiki/Releases/30/Schedule
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

[Bug 1685532] New: Upgrade perl-Pod-Tests to 1.20

[bugzilla]

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

Bug ID: 1685532
   Summary: Upgrade perl-Pod-Tests to 1.20
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Pod-Tests
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lxt...@gmail.com, perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



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

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

[Bug 1685531] New: Upgrade perl-Type-Tie to 0.014

[bugzilla]

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

Bug ID: 1685531
   Summary: Upgrade perl-Type-Tie to 0.014
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Type-Tie
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



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

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

Re: Looking for volunteers for a handful of Go package reviews

[Didier Fabert]

Hi,

golang-github-anacrolix-envpprof is done
(https://bugzilla.redhat.com/show_bug.cgi?id=1684936)

Is there a package which is blocking all others ? I have some time to do
review

Didier.

Le 04/03/2019 à 02:05, Robert-André Mauchin a écrit :
> Hello,
>
> I have several Go packages in need of a review for the latest Rclone version.
> I'm available for any review in exchange.
>
> - golang-github-anacrolix-dms
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684956
>
> - golang-github-anacrolix-ffprobe
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684950
> 
> - golang-github-anacrolix-envpprof
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684936
> 
> - golang-github-anacrolix-missinggo
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684940
> 
> - golang-github-RoaringBitmap-roaring
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684934
> 
> - golang-github-glycerine-go-unsnap-stream
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684906
> 
> - golang-github-mschoch-smat
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684924
> 
> - golang-github-tinylib-msgp
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684919
> 
> - golang-github-philhofer-fwd
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684908
> 
> - golang-github-ttacon-chalk
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684909
> 
> - golang-github-willf-bitset
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684925
> 
> - golang-github-anacrolix-tagflag
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684948
> 
> - golang-github-bradfitz-iter
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684933
> 
> - golang-github-docopt
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684938
> 
> - golang-github-huandu-xstrings
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684929
> 
> - golang-github-ryszard-goskiplist
>   https://bugzilla.redhat.com/show_bug.cgi?id=1684927
>
> Thanks to all!
>
> Robert-André
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 30 Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 30 schedule[1], with several
significant cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 30
packages must be submitted to
updates-testing and pass the relevant requirements[3] before they will be
marked as 'stable' and moved to the
fedora repository.

Today is also the Beta freeze[4]. This means that only packages which fix
accepted blocker or freeze exception
bugs[5][6] will be marked as 'stable' and included in the Beta composes.
Other builds will remain in updates-
testing until the Beta release is approved, at which point the Beta freeze
is lifted and packages can move to
'stable' as usual until the Final freeze.

Finally, today is the '100% code complete deadline' Change Checkpoint[5],
meaning that Fedora 30 Changes
must now be code complete, meaning all the code required to enable to the
new change is finished. The level
of code completeness is reflected as tracker bug state ON_QA. The change
does not have to be fully tested
by this deadline'.

Finally, today is also the Software String freeze[7], which means that
strings marked for translation in Fedora-
translated projects should not now be changed for Fedora 30.

Mohan Boddu

[1] https://fedoraproject.org/wiki/Releases/30/Schedule
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Vít Ondruch]

Dne 05. 03. 19 v 9:08 Adam Samalik napsal(a):
>
>
> On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth  > wrote:
>
> On 3/4/19 3:04 AM, Petr Šabata wrote:
> > You can view them as virtual repositories with dependencies.  I
> > think that might be the simplest way to put it.
> >
> > You can try playing with fedmod to generate your modulemd file or
> > you can just write it from scratch; it's not all that complicated.
>
> Why should I care? Please, win me over. (I'm being serious.)
>
>
> I think you should care if:


I am afraid you are missing one point. You need to care if somebody else
believes the points you list below are relevant. This is the issue.


Vít



>
> a) You need to maintain multiple versions of the same app/runtime/set
> of tools tools in Fedora (or an alternative to something that already
> exists), or
> b) You only want to maintain one source branch per package for all
> Fedora releases, or
> c) You could benefit from having a build recipe in case you maintain
> app/runtime/set of tools tools represented by multiple packages that
> need to be built in the right order
>
> But if any of the above is something that you need/want to do, then
> Modularity won't help you nor hurt you in any way.
>
>
> I view the current RPM system as reliable, standard, and
> well-documented. It's
> served me and the people I know that use it well for decades. I
> view Modularity as
> an answer to a question no one asked. It presents new problems
> that never existed
> and has been somewhat silently taking over RPM-land with very
> little community
> involvement.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> -- 
>
> Adam Šamalík
> ---
> Software Engineer
> Red Hat
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Adam Samalik]

On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth  wrote:

> On 3/4/19 3:04 AM, Petr Šabata wrote:
> > You can view them as virtual repositories with dependencies.  I
> > think that might be the simplest way to put it.
> >
> > You can try playing with fedmod to generate your modulemd file or
> > you can just write it from scratch; it's not all that complicated.
>
> Why should I care? Please, win me over. (I'm being serious.)
>

I think you should care if:

a) You need to maintain multiple versions of the same app/runtime/set of
tools tools in Fedora (or an alternative to something that already exists),
or
b) You only want to maintain one source branch per package for all Fedora
releases, or
c) You could benefit from having a build recipe in case you maintain
app/runtime/set of tools tools represented by multiple packages that need
to be built in the right order

But if any of the above is something that you need/want to do, then
Modularity won't help you nor hurt you in any way.


> I view the current RPM system as reliable, standard, and well-documented.
> It's
> served me and the people I know that use it well for decades. I view
> Modularity as
> an answer to a question no one asked. It presents new problems that never
> existed
> and has been somewhat silently taking over RPM-land with very little
> community
> involvement.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org