F40 Change Proposal: PostgreSQL 16 (Self-Contained)
by Aoife Moloney
Wiki Link: https://fedoraproject.org/wiki/Changes/PostgreSQL_16
Discussion.fpo Link:
https://discussion.fedoraproject.org/t/f40-change-proposal-postgresql-16-...
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
= PostgreSQL 16 =
{{Change_Proposal_Banner}}
== Summary ==
Update of default PostgreSQL stream (`postgresql` and `libpq`
components) in Fedora from version 15 to version 16. Since modularity
was marked as retired, there will also be a change in the packaging
concept.
== Owner ==
* Name: [[User:fjanus| Filip Januš]]
* Email: fjanus(a)redhat.com
== Detailed Description ==
The original package `PostgreSQL` will be retired. Since Fedora 40
there will be a separate component in the rpms namespace for each
shipped PostgreSQL. So postgresql15 for PG15 and postgresql16 for
PG16. Each PG stream will provide `postgresql` symbol and conflict
with each other. The choice of default stream will be made by building
sub-packages with appropriate names. (using `-n` in the `files`
section). This approach should solve, among other things, the problem
of possible duplicity. There is the following problem if we kept one
version to be shipped in unversioned postgresql component:
F40 - there is currently a default version PG15 (postgresql -> 15)<br>
F40 - there will be added version PG16 (postgresql -> 15, postgresql16)<br>
F40 - switch default version to PG16 (postgresql -> 16, postgresql16,
new postgresql15)<br>
If PG15 is to be present in F40, to follow non-modular concept the new
package is necessary. <br>
BUt such switch leads to duplicit packages postgresql and postgresql16
with the same content. <br>
Using just versioning packages would solve the described issue. The
proposed solution is described below.
Plan of the future structure of Postgresql versioning:<br>
Fedora 40 where PostgreSQL 16 is default:<br>
postgresql SRPM -> deprecated<br>
postrgresql15 SRPM -> postgresql15, postgresql15-server, ...<br>
postrgresql16 SRPM -> postgresql, postgresql-server, ...<br>
postrgresql17 SRPM -> postgresql17, postgresql17-server, ...<br>
Fedora 42 where PostgreSQL 17 is default:<br>
postgresql SRPM -> deprecated<br>
postrgresql15 SRPM -> postgresql15, postgresql15-server, ...<br>
postrgresql16 SRPM -> postgresql16, postgresql16-server, ...<br>
postrgresql17 SRPM -> postgresql, postgresql-server, ...<br>
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
== Feedback ==
== Benefit to Fedora ==
The latest stable software is provided for Fedora users.
Modules are no longer needed.
== Scope ==
* Proposal owners:
**Prepare PostgreSQL 16 as the default stream
**Prepare PostgreSQL 15 as a non-default stream
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Build PostgreSQL 16 (postgresql and libpq) for Rawhide
**Build PostgreSQL 15 for Rawhide
**Rebuild dependent packages against PostgreSQL 16
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible. So,
there shouldn't be any compatibility issues, but rebuild of the
dependent components is recommended.
Server plugins might require a newer version update because they
sometimes have explicit server requirements.
== How To Test ==
All PG server plugins should be installable.
`postgresql-setup --upgrade` command should succeed.
Test that all other software runs well with PostgreSQL 16.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade` after
installing PostgreSQL 16 server packages.
If users want to stick with PostgreSQL 15 for a little longer, there
will be PostgreSQL 15 as nondefault PostgreSQL stream
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires. Others should use libpq. In the
case of Postgresql-server, a rebuild should be done to ensure all
potential binary incompatibilities are handled.
* PostgreSQL server dependecies
** perl-DBD-Pg
** pgaudit
** qt
** qt3
** qt5-qtbase
** postgres-decoderbufs
** gambas3
** kdb
** kea
** libpqxx
** openvas-manager
** orafce
** pg-semver
** pgRouting
** pgadmin3
** pgsphere
** postgis
** postgresql-ip4r
** postgresql-pgpool-II
** qt3
** rdkit
** rhdb-utils
** timescaledb
** pg_repack
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
Revert the changes and provide PostgreSQL 15 only.
== Documentation ==
Upgrade strategy: https://www.postgresql.org/docs/16/upgrading.html
N/A (not a System Wide Change)
== Release Notes ==
Release notes for PostgreSQL 16 release:
https://www.postgresql.org/docs/16/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/16/release-16.html
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
6 months, 1 week
Fedora 33 Self-Contained Change proposal: Automatic RPM dependencies
on Python Extras
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PythonExtras
== Summary ==
The Python RPM dependency generator (that generates
<code>python3.Xdist(foo)</code> requirements) will be adapted to also
generate requirements on
[https://www.python.org/dev/peps/pep-0508/#extras Python extras] (e.g.
<code>python3.Xdist(foo[bar])</code>) whenever upstream metadata
indicate such dependency. An easy opt out mechanism will exist. A
supported way of adding metapackages that provide such Python extras
(e.g. <code>python3.Xdist(foo[bar])</code>) will be introduced. Change
owners will add the missing metapackages that would otherwise cause
broken dependencies (in non-modular packages).
== Owner ==
* Name: [[User:Torsava|Tomáš Orsava]]
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: <python-maint(a)redhat.com>
== Detailed Description ==
=== The problem ===
[https://www.python.org/dev/peps/pep-0508/#extras Python extras] are a
way for a Python package (called "distribution" or "distribution
package" upstream) to declare that extra dependencies are required for
additional functionality.
For example Python package <code>requests</code> has several standard
dependencies (e.g. <code>urllib3</code>). But it also declares an
extra named <code>requests[security]</code> which lists additional
dependencies (e.g. <code>pyOpenSSL</code>) if you want to use this
additional functionality. The Python package code handles the missing
optional dependency gracefully -- e.g. it won't crash but might
instruct the user to install <code>requests[security]</code> if needed
by a warning or an actionable error message.
Python packages included in Fedora as RPMs automatically create a
special Provides in the format <code>python3.Xdist(foo)</code> (and
<code>python3dist(foo)</code>) where <code>foo</code> is the upstream
Python package distribution name and X is the Python minor version.
That way you can require any Python package without knowing under
which name it was packaged in Fedora. And these tags are also
automatically used by the Python dependency generator, which reads
upstream Python metadata and creates dependencies on these Provides.
However, Python extras are not yet handled by the Provides tags which
leads to imperfections and problems in declared dependencies.
=== Status quo ===
Currently in Fedora (before this change), no package provides
<code>python3.Xdist(foo[bar])</code> for the <code>foo[bar]</code>
Python extra. As a direct result of this, no package can require it.
The automatic RPM Python dist dependency generator only generates an
incomplete requirement on the base package
(<code>python3.Xdist(foo)</code>) in such cases.
The transitive extra dependencies were often needed to be hardcoded
manually. I.e. when <code>foo</code> requires <code>bar[baz]</code>,
package <code>bar</code> does not require the additional dependencies
for the <code>bar[baz]</code> extra. Thus <code>foo</code> needs to
hardcode those dependencies manually. For example:
[https://src.fedoraproject.org/rpms/poetry/c/97fa3d908]. This leads to
possibly missing, broken and/or outdated superfluous dependencies.
=== Extras metapackages ===
In this change proposal, we propose to solve the problem using
metapackages. The following metapackage represents the
<code>setuptools_scm[toml]</code> extra for the
<code>python3-setuptools_scm</code> RPM package
(<code>python-setuptools_scm</code> source package):
%package -n python3-setuptools_scm+toml
Summary: Metapackage for python3-setuptools_scm: toml extra
Requires: python3-setuptools_scm = %{?epoch:%{epoch}:}%{version}-%{release}
%description -n python3-setuptools_scm+toml
This is a metapackage bringing in toml extra requires for
python3-setuptools_scm.
It contains no code, just makes sure the dependencies are installed.
%files -n python3-setuptools_scm+toml
%ghost %{python3_sitelib}/*.egg-info
Notice several things:
* The package has a hard dependency on <code>python3-setuptools_scm =
%{?epoch:%{epoch}:}%{version}-%{release}</code>. While this could be
in theory generated by the dependency generator, the change owners
have decided not to do that to allow certain leeway for
experimentation. However, the dependency will created by the macro
helper below. Technically, <code>%{?_isa}</code> should also be used
for arched packages, but in practice we believe it can be omitted.
* The package contains no files except the <code>%ghost</code>
metadata. This is needed for the dependency generator to have access
to the upstream metadata of this package.
The [https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/19
updated RPM Python dist dependency generator] parses the extras name
from the subpackage name by splitting it on the <code>+</code> sign.
This naming scheme is not new, it is copied from Rust packaging. Five
Python packages in Fedora already use the same scheme for similar
metapackages representing Python extras. And normalized Python
distribution package names (or extras names) don't naturally contain
the <code>+</code> sign. (Neither do existing Fedora packages prefixed
with <code>python3-</code>, except the 5 components already
mentioned.)
The metapackage can have additional features if desired. For example:
* It can obsolete/provide other names (e.g. obsoleted extras packages)
* It can have manual strong or weak dependencies on other (possibly
non-Python) packages
* It can contain files excluded from the "base" package (if such files
only make sense with the extra and the base package does not fail
without them)
The "base" package (in this case <code>python3-setuptools_scm</code>)
can optionally Require/Recommend/Suggest a Python extras metapackage
if the packager deems it useful.
The change for the RPM Python dist dependency generator is prepared in:
* https://github.com/torsava/rpm/pull/2 (PR for upstream RPM will
follow after this change is discussed in Fedora)
* https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/19
(to be adapted based on feedback and merged in Fedora once the change
is approved)
=== Macro helper ===
For the most common case, the change owners have prepared a macro
helper in https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/59
To generate the example above, it should be used like this:
%{?python_extras_subpkg:%python_extras_subpkg -n
python3-setuptools_scm -i %{python3_sitelib}/*.egg-info toml}
* The <code>%{?python_extras_subpkg:...}</code> way of using this
macro ensures the spec file remains valid for older Fedora/EL
releases, where this code will do nothing.
* The <code>-n</code> option specifies the name of the "base" package.
* The <code>-i</code> option specifies the <code>%files %ghost</code>
path (glob) to the the metadata directory (the <code>.dist-info</code>
or <code>.egg-info</code> directory)
* The one or more positional arguments specify the extra(s) name(s) —
multiple metapackages are generated when multiple names are provided.
Other possible arguments:
* The <code>-f</code> option (conflicts with <code>-i</code> and
<code>-F</code>) can specify the relative path to the filelist for
this metapackage (which should contain the <code>%files %ghost</code>
path (glob) to the the metadata directory). This API is prepared for
integration with <code>pyproject-rpm-macros</code>.
* The <code>-F</code> flag (conflicts with <code>-i</code> and
<code>-f</code>) can be used to skip the <code>%files</code> section
entirely (if the packager wants to construct it manually).
Note that this macro generates all the subpackage definition sections
(<code>%package</code> including the Summary and Requires on the base
package, <code>%description</code> and <code>%files</code>), and hence
it cannot be extended with custom Provides/Obsoletes/Requires/etc.
This macro is designed to fit the most common uses. It doesn't
currently cover all use cases. Packagers can, however, construct the
subpackage manually if they need custom features not covered by
<code>%python_extras_subpkg</code>. In the future, the API of the
macro can be extended if there is demand.
See the [https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/59
linked pull request] for example outputs.
Due to technical limitations, the macro helper never generates
requirement on the arched <code>BASE_PACKAGE%{?_isa} =
%{?epoch:%{epoch}:}%{version}-%{release}</code>. It only adds
<code>Requires: BASE_PACKAGE =
%{?epoch:%{epoch}:}%{version}-%{release}</code>) because a
[https://github.com/rpm-software-management/rpm/issues/689 macro
cannot reliably detect if the subpackage is arched or not]. The change
owners believe the resolver will do the right thing by default. If
there are problems with this approach, an additional flag (such as
<code>-a</code>) can be introduced to indicate an arched base package.
=== Why is there no automatic extras discovery? ===
[http://lists.rpm.org/pipermail/rpm-ecosystem/2020-February/000730.html
RPM is not capable of creating dynamic subpackages] based on the
content in <code>%{buildroot}</code> or on the unpacked sources
(<code>%{_builddir}</code>) yet.
Hence, we require the packager to manually list which Python extras
(if any) should be packaged as metapackages. Not all extras are useful
for us anyway, as there are often extras representing the
build/dev/doc/test dependencies of the project.
In the future (once/if RPM supports this), the generators can be
extended with auto-discovery of Python extras (with filtering).
=== Automatic provides generator ===
To continue with our example, the
<code>python3-setuptools_scm+toml</code> subpackage will Provide
<code>python3.Xdist(setuptools_scm[toml])</code> (and also
<code>python3dist(setuptools_scm[toml])</code>).
An attempt to package a nonexsiting extra (e.g.
<code>python3-setuptools_scm+nopenopenope</code>) will result in build
failure with an human-readable error message.
=== Automatic requires generator ===
If a Python package requires <code>setuptools_scm[toml]</code>, the
Fedora RPM package will require
<code>python3.Xdist(setuptools_scm[toml])</code> and also
<code>python3.Xdist(setuptools_scm)</code>. In theory, the second
requirement is redundant, but in practice, it makes it easier (and
less error prone) to query package dependencies in Fedora (e.g. using
<code>dnf repoquery</code>).
The packaged extras will also Require additional dependencies listed
in their Python metadata, in the case of
<code>python3-setuptools_scm+toml</code>, it will require
<code>python3.Xdist(toml)</code> (because on the Python level,
<code>setuptools_scm[toml]</code> requires <code>toml</code>).
Packagers can opt out from automatically generated dependencies on
Python extras by defining the <code>%_python_no_extras_requires</code>
macro to any value (usually <code>1</code>) in the spec file. This
should be only a a temporary measure until the missing extra is
packaged. If the upstream dependency information is not accurate,
please work with upstream to fix it.
=== Coordinated effort to avoid breakage ===
The change owners have
[https://copr.fedorainfracloud.org/coprs/g/python/python-extras/
collected data about non-modular packages in Copr]. Note that ~270
packages failed to build for unrelated reasons and hence we miss data
for them. However, ~3300 packages built successfully.
The following extras metapackages will be added to avoid broken dependencies:
autobahn[twisted]
cachecontrol[filecache]
cairocffi[xcb]
cli-helpers[styles]
docker[ssh]
fonttools[ufo]
fonttools[unicode]
ipython[notebook]
lunr[languages]
oauthlib[signedtoken]
pyjwt[crypto]
raven[flask]
requests[security]
requests[socks]
tabulate[widechars]
twisted[tls]
vistir[spinner]
The following components will be modified:
python-autobahn
python-CacheControl
python-cairocffi
python-cli-helpers
python-docker
fonttools
ipython
python-lunr
python-oauthlib
python-jwt
python-raven
python-requests
python-tabulate
python-twisted
python-vistir
When we added the metapackages for these extras in our testing Copr,
no new broken requires on Python extras were generated. In other
words, these new extras subpackages don't require adding any more
extras subpackages. No extras are required by the remaining Python 2
packages in Fedora.
Once the change in the dependency generator is deployed in rawhide,
the change owners will monitor all newly added requires on missing
extras and will add new metapackages as needed.
5 source packages in Fedora already have Python extras
meta-subpackages with the proposed naming pattern, but they don't have
any listed <code>%files</code>. They will be non-intrusively adapted
via pull requests — by adding the <code>%ghost</code> file entry to
the metapackage(s). Maintainers can then decide whether to opt for
simpler rawhide only specfile with <code>%python_extras_subpkg</code>
or to maintain the current compatibility. This concerns the following
18 subpackages:
python3-dask+{array,bag,dataframe,delayed}
python3-django-storages+{azure,boto,boto3,dropbox,libcloud,sftp}
python3-dns-lexicon+{easyname,gratisdns,henet,hetzner,plesk,route53}
python3-drf-yasg+validation
python3-prometheus_client+twisted
==== Modular packages ====
The change owners are only cable of monitoring and adapting
non-modular packages. Due to long standing issues, we are unable to
inspect, query (or do a targeted rebuild of) modular content:
* https://pagure.io/modularity/issue/160
* https://pagure.io/modularity/issue/163
* https://pagure.io/modularity/issue/165
If there are people available to help with this problem, the change
owners will gladly accept their help, we are not excluding modular
content because we would like to do it, but because we don't know how
to work with it at scale.
=== How to add Python extras subpackage to my package? ===
In this section, we'll describe a step-by-step guide of adding the
Python extras subpackage to your package. Imagine you maintain
<code>python-requests</code> and a maintainer of a dependent package
contacts you: "I would like you to add a subpackage for
<code>requests[security]</code>, because my package requires it."
# Locate the <code>%files</code> section for
<code>python3-requests</code> package in
<code>python-requests.spec</code>.
# Find the entry for <code>.egg-info</code> or <code>.dist-info</code>
metadata directory. If the entry is generalized with globs like
<code>%{python3_sitelib}/*</code>, please make the <code>%files</code>
section more explicit while at it. Copy the line with the metadata
directory. In this guide we assume it is
<code>%{python3_sitelib}/*.egg-info</code>.
# Locate the <code>%description</code> of the
<code>python3-requests</code> package.
# After the description, add:
<code>%{?python_extras_subpkg:%python_extras_subpkg -n
python3-requests -i %{python3_sitelib}/*.egg-info security}</code> on
a separate line.
# Build the package (e.g. in local mock).
# Verify the <code>python3-requests+security</code> package is build
and provides <code>python3dist(requests[security])</code>.
# See if the new extras package doesn't have dependencies on packages
missing from Fedora (extras or "basic") and proceed with adding those
if needed.
# Ship the change in Fedora 33+. It should do nothing in Fedora 31/32
or current EPELs.
=== Packaging guidelines ===
The change owners will describe this concept in the Python packaging
guidelines and will propose the following rules for the Fedora
Packaging Committee to approve:
* Packagers MAY add Python extras metapackages as needed.
* The Python extras metapackages MUST require the base package (exact NEVR).
* Packagers MAY add strong or weak dependencies on the extras
metapackages from the base package as they see fit.
* Packagers SHOULD NOT add Python extras metapackages with
dependencies only useful for maintaining the package (usually extras
called dev/test/doc/build/...).
** Optional: Packagers MAY package tests separately into the
<code>[test]</code> or <code>[testing]</code> extras subpackage.
* If a Fedora package requires a Python extra of a different package,
the extras metapackage MUST be added to that package to avoid broken
dependencies.
* Packagers MAY temporarily disable the automatic requires on extras
subpackages (by defining <code>%_python_no_extras_requires</code>)
until the missing metapackage is introduced, but they SHOULD notify
the maintainer of the package they depend on about the situation.
* If upstream drops an extra, even though it is discouraged by
upstream documentation
([https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-ext...
see final paragraph]), the metapackage SHOULD be Obsoleted from the
base package or, if there is continuity, from another extras
metapackage.
* If the upstream Python package name contains <code>+</code>, it MUST
be replaced with <code>-</code> in package names (in accordance with
the upstream [https://www.python.org/dev/peps/pep-0503/#normalized-names
Python package names normalization]).
== Feedback ==
This has been briefly discussed in general terms
[https://github.com/rpm-software-management/rpm/issues/1061 upstream].
People tend to agree that some solution is needed. The concrete
proposal contained in this Fedora Change is based on the discussion,
but has received no feedback yet.
More feedback will be documented here once the change proposal is
announced and discussed in Fedora.
== Benefit to Fedora ==
* Packages will have more accurate automatic dependencies, and the
hard-to-maintain and error prone manual transitive (and other)
dependencies can be dropped.
* There will be less missing and redundant dependencies.
* Python packagers will have less manual dependencies to worry about
and less problems to workaround.
* The handling of Python extras will be standardized.
* Overall, the Python ecosystem in Fedora will be closer to upstream.
== Scope ==
* Proposal owners:
** Polish and merge the code changes for
<code>python-rpm-generators</code> and <code>python-rpm-macros</code>
linked above.
** Add the 17 missing extras metapackages listed in this change to
avoid broken dependencies (using pull requests or provenpackager
powers if need be).
** Adapt the 5 existing Python extras subpackages listed in this
change to work with the dependency generator (using pull requests, or
provenpackager powers if need be).
** Monitor new dependencies on Python extras subpackages, add extras
subpackages where needed (using pull requests, or provenpackager
powers if need be).
** Propose the updated Python packaging guidelines to FPC for approval.
** Provide help and guidance for packagers.
** Optional: Prepare <code>pyproject-rpm-macros</code> integration of
this change.
* Other developers:
** No immediate action necessary.
** They can opt in for more metapackages with extras.
** They can review and merge pull requests.
** They should follow the updated Python packaging guidelines if the
changes are approved by FPC.
* Release engineering: No releng impact anticipated. The new
dependencies will be primarily generated by the mass rebuild, but if
the mass rebuild is missed, the package maintainers or change owners
can rebuild the packages that will gain the new automatic Requires is
on Python extras.
* Policies and guidelines: Yes, see detailed description.
* Trademark approval: Not needed for this Change.
== Upgrade/compatibility impact ==
No impact anticipated.
== How To Test ==
Check that there are packages that Require
<code>python3.9dist(basename[extrasname])</code>. You can use the
following repoquery:
dnf repoquery --repo=rawhide --whatrequires 'python3.9dist(*\[*\])'
Check that there are Python extras metapackages with the correct
Provides, for example by installing the packages returned by the above
query, or manually via queries like:
dnf repoquery --repo=rawhide --whatprovides
'python3.9dist(requests\[security\])'
To query all existing Python extras metapackages, you can use:
dnf repoquery --repo=rawhide --provides -a | grep -E
'python(3\.9|2\.7)dist\(\S+\[\S+\]\)'
And lastly, to query all required Python extras metapackages:
dnf repoquery --repo=rawhide --requires -a | grep -E
'python(3\.9|2\.7)dist\(\S+\[\S+\]\)'
== User Experience ==
When installing Python RPM packages, the dependencies are more likely
to fulfill user expectations, as they will more closely adhere to the
behavior of pip (the Python package installer).
== Dependencies ==
Nothing.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** Soft: The change owners will disable the requirements generator by
default and rebuild (or untag if FTBFS) packages with broken
dependencies caused by the change.
** Hard: The change owners will revert everything and rebuild (or
untag if FTBFS) packages with new requirements/provides caused by the
change.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
The packaging guidelines will be the documentation if approved. If
not, this Fedora Change shall serve as the documentation.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 10 months
Containers: we're asking for ponies, so here's a suggestion for the
Minimum Viable (Modular) Pony Show
by Matthew Miller
At DevConf.cz, I said that 2016 needed to be the year of the _show_
part of "show & tell" for what we started with the "rings" proposal and
now what we're calling, vaguely, "modularity".
Some of that is scary, because anything really new always is. It's
important that we do this in a way that *both* brings useful new
functionality _and_ doesn't break what we have.
In the commercial world, there's a concept of "minimum viable product" --
not done, not perfect, but what it takes to actually start solving problems
and providing value. In Fedora, we're not in business in the same way, but
some of the same can apply. So, here's my suggestions for a "minimum viable
demo" for what a container-based module might look like in Fedora.
Particularly, when I've spoken to people about delivering parts of Fedora as
containers, the part about tracking security and proving updates becames
disturbingly hand-wavy, with "yeah, of course, we'll do something to cover
that". I think to be successful, we need to make sure that this is addressed
early. So, this proposal for a demo I'd like to see.
I've broken it down into three parts of increasing complexity and
usefulness: starting with "and I want a pony", then moving up to "actually,
a unicorn", and then "also, could you put wings on that?"
So, first:
The Minimum Viable Pony
-----------------------
This is a basic web server module delivered as a container.
Part A: the basic module:
* Answers on port 80 and serves out static web pages.
* Content comes from /var/www/html... or another container, or whatever.
* Doesn't even need to be configurable. It's a demo.
* It's composed entirely from RPMs already existing in Fedora.
Part B: DNF Plugin to list CVEs
* Works like https://docs.fedoraproject.org/en-US/Fedora/17/html/Security_Guide/sect-S...
- lists all RPMs on host system where a security update is available
- can list by CVE
- also by Bugzilla
- also with link to update notice
- with various breakdowns by severity level
- **additionally** lists "modules" which need updates (with same links)
- has option to list which specific RPMs within the module have the
problem.
So that's a good start. As a sysadmin, I'm feeling a little less scared
about. But we also need...
To Take It to Unicorn Level
---------------------------
It's all well and good to fix the problem, but we also need to be able to
fix it. So, the next level is:
* Image is built in Fedora's new Layered Image Build Service
https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
* If there is a security vulnerability in any RPM that is in the image, it
is automatically rebuilt and made available somewhere.
* And automatically tested!
- Here, just a basic test that makes sure that input web content comes
out. It's a proof-of-concept so no real in-depth testing is needed.
* And, then, a dnf plugin which actually downloads and applies the update.
Now, not only do we have comforting tooling (minimizing change pain), we
also have a real, practical improvement (there will be cake!). In the
current system, while we do hands-on testing of individual updates, they
aren't necessarily tested in the application to which they apply. For
example, if the web server here is Nginx and the security flaw in the SSL
library, current update testing does not guarantee that the update has been
tested *for that use*. But this will. Plus, in addition to whatever human
oversight, there will be an _automatic_ test.
So that's pretty good. But finally, to get to the glorious future, I'd also
like to see this unicorn become also a pegasus (my daughter tells me that
this makes it an "alicorn")...
Taking Flight
-------------
Same as above, but with two new things:
New Thing One:
* Instead of RPMs, a module which uses some non-RPM upstream packaging
format as part of its composition
- Ruby gem, Python egg or wheel, Java jar... whatever
* And the DNF list-security command still works
- and the verbose flag now tells us about the CVEs or whatever for the
non-RPM package
New Thing Two:
* There is enough metadata and intelligence such that when the new
container is updated, that update happens without downtime. This may
involve multiple containers.
* If the update fails locally for some reason (despite the best efforts at
upstream testing), it's rolled back automatically
From here, I can imagine all sorts of other mythical creatures. But, you
know, for a start. What do you think?
As a user/sysadmin, is there something more you'd like to see? If
you're skeptical about containers, would this make you feel better? If
not, what might?
If you're excited about them, does this seem like a useful start?
What's missing?
And, of course, if you're a developer working on this stuff, can I have
ponies please?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F29 to F30
by Robert-André Mauchin
On Sunday, 14 April 2019 08:55:32 CEST Hirotaka Wakabayashi wrote:
> Hello
>
> I tested upgrades from F29 to F30. I use the following images:
> https://download.fedoraproject.org/pub/fedora/linux/releases/29/Cloud/x86_64
> /images/Fedora-Cloud-Base-Vagrant-29-1.2.x86_64.vagrant-virtualbox.box
> https://download.fedoraproject.org/pub/fedora/linux/releases/29/Cloud/x86_6
> 4/images/Fedora-Cloud-Base-29-1.2.x86_64.qcow2
>
> On the image for Vagrant, I failed upgrades I usually use this image for
> rpm packaging.``` [vagrant@fedora29 ~]$ sudo dnf --releasever=30
> --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing
> distro-sync Fedora Modular 30 -
> x86_64
> 650 kB/s | 2.3 MB
> 00:03 Fedora Modular 30 - x86_64 -
> Updates
> 219 B/s | 257 B 00:01 Fedora
> 30 - x86_64 - Test
> Updates
> 1.8 MB/s | 14 MB 00:07
> Fedora 30 - x86_64 -
> Updates
> 234 B/s | 257 B
> 00:01 Fedora 30 -
> x86_64
> 1.1 MB/s | 54
> MB 00:48 Error:
> Problem 1: problem with installed package
> gofed-infra-1.0.0-0.21.rc1.fc29.noarch -
> gofed-infra-1.0.0-0.21.rc1.fc29.noarch does not belong to a distupgrade
> repository - nothing provides python2.7dist(git) needed by
> gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides
> python2.7dist(hglib) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch -
> nothing provides python2.7dist(koji) needed by
> gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides
> python2.7dist(python-gitdb) needed by
> gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides
> python2.7dist(tarfile) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch -
> nothing provides python2.7dist(urllib2) needed by
> gofed-infra-1.0.0-0.22.rc1.fc30.noarch Problem 2: problem with installed
> package gofed-gofedlib-1.0.0-0.21.rc1.fc29.x86_64 -
> gofed-gofedlib-1.0.0-0.21.rc1.fc29.x86_64 does not belong to a distupgrade
> repository - nothing provides python2.7dist(jinja2) = 2.8 needed by
> gofed-gofedlib-1.0.0-0.22.rc1.fc30.x86_64 - nothing provides
> python2.7dist(markupsafe) = 0.23 needed by
> gofed-gofedlib-1.0.0-0.22.rc1.fc30.x86_64 Problem 3: problem with installed
> package gofed-1.0.0-0.21.rc1.fc29.x86_64 - package
> gofed-1.0.0-0.22.rc1.fc30.x86_64 requires gofed-infra =
> 1.0.0-0.22.rc1.fc30, but none of the providers can be installed -
> gofed-1.0.0-0.21.rc1.fc29.x86_64 does not belong to a distupgrade
> repository - nothing provides python2.7dist(git) needed by
> gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides
> python2.7dist(hglib) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch -
> nothing provides python2.7dist(koji) needed by
> gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides
> python2.7dist(python-gitdb) needed by
> gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides
> python2.7dist(tarfile) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch -
> nothing provides python2.7dist(urllib2) needed by
> gofed-infra-1.0.0-0.22.rc1.fc30.noarch Problem 4: problem with installed
> package gofed-resources-1.0.0-0.21.rc1.fc29.noarch - package
> gofed-resources-1.0.0-0.22.rc1.fc30.noarch requires gofed-gofedlib =
> 1.0.0-0.22.rc1.fc30, but none of the providers can be installed -
> gofed-resources-1.0.0-0.21.rc1.fc29.noarch does not belong to a distupgrade
> repository - nothing provides python2.7dist(jinja2) = 2.8 needed by
> gofed-gofedlib-1.0.0-0.22.rc1.fc30.x86_64 - nothing provides
> python2.7dist(markupsafe) = 0.23 needed by
> gofed-gofedlib-1.0.0-0.22.rc1.fc30.x86_64 (try to add '--skip-broken' to
> skip uninstallable packages)
> ```
>
> On the image for OpenStack, dependencies are successfully resolved.
> ```
> Transaction Summary
> ============================================================================
> ============================================================================
> ========================== Install 20 Packages
> Upgrade 392 Packages
>
> ...
>
> Total download size: 282 M
> Is this ok [y/N]:
> Operation aborted.
> ```
>
> Upgrades are successfully completed while I found scriptlets in dbus-daemon
> and systemd are failed because of "Failed to reload daemon: Access
> denied".```
> Transaction Summary
> ============================================================================
> ============================================================================
> ========================== Install 20 Packages
> Upgrade 392 Packages
>
> Total download size: 282 M
> Is this ok [y/N]: y
>
> ...(snip)...
> Upgraded: dbus-daemon-1:1.12.10-1.fc29.x86_64
> Running scriptlet:
> dbus-daemon-1:1.12.10-1.fc29.x86_64
>
> 663/807 Failed to reload daemon: Access denied
> warning: %triggerpostun(systemd-239-3.fc29.x86_64) scriptlet failed, exit
> status 1
>
> Error in <unknown> scriptlet in rpm package dbus-daemon
> Upgraded: systemd-pam-239-3.fc29.x86_64
>
> ...(snip)...
> Upgraded: libgcc-8.2.1-2.fc29.x86_64
> Running scriptlet:
> libgcc-8.2.1-2.fc29.x86_64
>
> 807/807 Running scriptlet:
> filesystem-3.10-1.fc30.x86_64
>
> 807/807 Running scriptlet:
> sssd-common-2.1.0-2.fc30.x86_64
>
> 807/807 Running scriptlet:
> kernel-core-5.0.7-300.fc30.x86_64
>
> 807/807 Running scriptlet:
> rootfiles-8.1-24.fc30.noarch
>
> 807/807 Running scriptlet:
> libgcc-8.2.1-2.fc29.x86_64
>
> 807/807 Running scriptlet:
> glibc-common-2.29-9.fc30.x86_64
>
> 807/807 Running scriptlet:
> shared-mime-info-1.12-2.fc30.x86_64
>
> 807/807 Running scriptlet:
> glib2-2.60.0-3.fc30.x86_64
>
> 807/807 Running scriptlet:
> systemd-241-6.gita2eaa1c.fc30.x86_64
>
> 807/807 Failed to reload daemon: Access denied
> warning: %triggerin(systemd-241-6.gita2eaa1c.fc30.x86_64) scriptlet failed,
> exit status 1
>
> Error in <unknown> scriptlet in rpm package systemd
> Running scriptlet:
> systemd-udev-241-6.gita2eaa1c.fc30.x86_64
>
> 807/807 Running scriptlet:
> man-db-2.8.4-4.fc30.x86_64
>
> 807/807 Running scriptlet: info-6.6-1.fc30.x86_64
>
> ...(snip)...
> Complete!
> [fedora@fedora29 ~]$
> ```
>
> Best Regards,
> Hirotaka Wakabayashi
>
Gofed is Python 2 only, and the author jchaloup has moved to other things.
If you used it to generate SPEC for Go, you can test go2rpm:
https://pagure.io/GoSIG/go2rpm
5 years
Re: [Modularity] A proposal for stream naming
by Petr Šabata
On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote:
> Okay, so, I decided to get my hands dirty with this to make sure my
> conceptual understanding stays in sync with the reality. And, it turns
> out we really do need a system-tools module. So, I'm going to make
> that. And in doing so, I ran into something I think is unresolved.
>
> An early decision needed when making a module is the label for the
> stream — that is, the dist-git branch it builds from. The convention is
> that within a stream, interfaces remain the same (just as now we expect
> big changes from release to release, not within f25 or f26). For
> modules which correspond primarily to a single piece of software (and
> associated stuff), it makes sense for the stream to match the major
> version of the software: module nodejs might have streams for 8 and 10,
> and httpd might have streams for 2.4 and 2.6.
>
> In fact, let's make that a guideline. I believe the existing
> https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_st...
> doesn't have any rules, so let's make one. Specifically:
I see those guidelines need to be updated to match reality.
/me makes a note to review them.
> * Modules which correspond primarily to a single application or
> versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
> use a stream label corresponding to the major version of that software
> (e.g. 2.4 or 8)
So if I'm reading this correctly, you're proposing Fedora should
forbid packagers from creating alternative streams for the same
major release of such software? I can imagine different variants
of httpd 2.4, built with different compile time options, bundling
different components, having different module metadata and such.
I agree there should be some recommendations on stream naming
but this feels far too strict for no reason.
> * Such modules MAY additionally have a "latest" stream, which would be
> "rolling release" of the latest stable version (as opposed to master,
> which corresponds to rawhide and may be unstable).
Sounds like the no-more-alphas Rawhide. Such "latest" streams
would drop major changes/rebases on the end users' systems.
It makes sense to have this, especially for developers, but
we should warn people that it's not the best choice for stable
systems and that... it will eat their babies ;)
> So far, easy, I think. But what about modules like mine which are
> collections of stuff? We could give them an arbitrary version and
> increment that. Or, since this module will to follow the same 13-month
> lifecycle of a base Fedora release, and make big changes in new streams
> on the same cadence, it is tempting to use "f26", "f27" and so on. I
> think, though, we want to avoid this, because it introduces a
> conceptual overload that will become confusing and limiting.
+1
> On the other hand, I want a label that tells people what to expect.
> Langdon suggested that expected EOL might be a good way to do this. So,
> I propose a convention that modules which do not correspond to single
> specific versioned software all follow this convention:
There are still some open questions regarding EOLs.
For instance:
Are they bound to the artifact or could that depend on the
context? Like "this module will go EOL next year for standard
Fedora and nobody will care to make it work with the latest
Platform but we'll still support it in the context of this LTS
spin / derived distro / whatnot".
Can EOL be extended for already released artifacts and if so, do
we need to issue an update to let users know through refreshing
their metadata?
Answers to these questions help us decide whether EOL metadata
should be bundled with the module, inside modulemd in the
repodata, or whether it belongs in an external system such
as PDC.
It also affects many other things all over the place such as
UX, system profiles or extended module dependency selectors.
It's not as simple as it may sound.
> Each such "collection" module MUST have one or both of the following:
>
> * A "latest" rolling stream (As above, this would be separate from
> "rawhide", as "latest stable", but could update frequently and
> arbitrarily.)
By the way, should rawhide streams be called rawhide or would
master be fine? Stream names come directly from dist-git branch
names but of course there could be a hardcoded exception in
MBS that does s/master/rawhide/.
Just bikeshedding.
> * One or more streams corresponding to "end of life no earlier than",
> in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for
> 'until'? Or "fYYMM" for 'fedora' — which might make sense if we get
> to my dream of mixing and matching with CentOS modules....)
See my EOL-related points above. Plus this would be ugly :P
> Additionally and for all of our sanity, I suggest:
>
> * Valid module end-of-life dates are always either June or December,
> corresponding to the Fedora schedule of early May / late October
> base releases. So, f1806 or f1812, but not f1810 or f1901.
Sounds like a valid recommendation rather than a necessary rule.
> I know there is some work on stream-to-stream upgrades in modularity;
> that work could take advantage of this convention.
>
> So, we'd have:
>
> httpd 2.4
> httpd 2.6
> nodejs 8
> nodejs 10
> sysadmin-tools latest
> sysadmin-tools f1812
> sysadmin-tools f1906
>
> Does this make sense? Do you have improvements or entirely better
> ideas?
>
> I have an alternate idea too: "collection" type modules would
> use arbitrary integer versions starting with 1 and increase only if the
> content undergoes a major switch. ALL module streams would contain EOL
> information after the version number separated by a ":". This EOL info
> would be a date as above, or the string "latest", _or_ the string
> "stable", indicating that no abi-breaking changes are expected ever and
> that we basically have no known EOL.
I like simple integer approach and it feels natural from an
engineer's point of view. I think. I can also imagine using
years or years.months, depending on how often the module
maintainer decides to release a new... thing.
Like "tools 2017", "tools 2017.6". *shrugs*
But I don't really have a preference.
I wouldn't include EOL directly in the stream (i.e. branch)
name but I totally agree it needs to be prominently displayed
in any user interface that deals with modules. No matter where
the tools get it from.
":" is one of the symbols still considered for name:stream
separation, if it's going to change from the "-" used currently.
I also like the idea of a stable marker. Not only users but
even the pipeline needs to know.
Anyway, thanks for doing this,
P
> With this alternate proposal, we'd have:
>
> httpd 2.4:stable
> httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...)
> nodejs 8:f1912 (because that's upstream eol)
> nodejs 9:f1806 (if someone wants to do the work for a non-lts release)
> nodejs 10:f2106 (or maybe e2012)
> sysadmin-tools 1:latest
> sysadmin-tools 1:f1812
> sysadmin-tools 1:f1906
>
>
> --
> Matthew Miller
> <mattdm(a)fedoraproject.org>
> Fedora Project Leader
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
6 years, 9 months
Re: Donate 1 minute of your time to test upgrades from F39 to F40
by Sérgio Basto
On Thu, 2024-03-07 at 11:15 +0000, Sérgio Basto wrote:
> On Thu, 2024-03-07 at 10:27 +0000, Barry Scott wrote:
> >
> >
> >
> >
> > On 21/02/2024 07:11, Miroslav Suchý wrote:
> >
> > >
> > > dnf --releasever=40 --setopt=module_platform_id=platform:f40 \
> > > --enablerepo=updates-testing \
> > > $(rpm -q fedora-repos-modular >/dev/null && echo --
> > > enablerepo=updates-testing-modular) \
> > > --assumeno distro-sync
> > >
> >
> > Fedora KDE spin - Intel CPU AMD GPU -
> >
> > Error:
> > Problem: problem with installed package blender-1:4.0.2-
> > 1.fc39.x86_64
> > - blender-1:4.0.2-1.fc39.x86_64 from @System does not belong to
> > a distupgrade repository
> > - nothing provides libopenvdb.so.10.1()(64bit) needed by blender-
> > 1:4.0.2-1.fc40.x86_64 from fedora
> > (try to add '--skip-broken' to skip uninstallable packages)
>
> is the combination of
> Bug 2259558 - F40FailsToInstall: blender
> Bug 2261013 - blender: FTBFS in Fedora rawhide/f40
>
Blender is FTBFS because :
DEBUG util.py:461: Failed to resolve the transaction:
DEBUG util.py:461: Problem 1: package usd-devel-23.11-2.fc40.aarch64
requires libusd_ms.so.0.23.11()(64bit), but none of the providers can
be installed
DEBUG util.py:461: - package usd-devel-23.11-2.fc40.aarch64 requires
usd-libs(aarch-64) = 23.11-2.fc40, but none of the providers can be
installed
DEBUG util.py:461: - conflicting requests
DEBUG util.py:461: - nothing provides
libboost_python312.so.1.81.0()(64bit) needed by usd-libs-23.11-
2.fc40.aarch64
DEBUG util.py:461: - nothing provides libopenvdb.so.10.1()(64bit)
needed by usd-libs-23.11-2.fc40.aarch64
DEBUG util.py:461: - nothing provides libdraco.so.8()(64bit) needed by
usd-libs-23.11-2.fc40.aarch64
DEBUG util.py:461: Problem 2: package openshadinglanguage-devel-
1.12.14.0-9.fc40.aarch64 requires liboslquery.so.1.12()(64bit), but
none of the providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires liboslexec.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires liboslcomp.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires liboslnoise.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires libtestshade.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires openshadinglanguage-libs(aarch-64) = 1.12.14.0-
9.fc40, but none of the providers can be installed
DEBUG util.py:461: - conflicting requests
DEBUG util.py:461: - nothing provides
libboost_thread.so.1.81.0()(64bit) needed by openshadinglanguage-libs-
1.12.14.0-9.fc40.aarch64
DEBUG util.py:461: Problem 3: package OpenImageIO-devel-2.4.17.0-
1.fc40.aarch64 requires libOpenImageIO_Util.so.2.4()(64bit), but none
of the providers can be installed
DEBUG util.py:461: - package OpenImageIO-devel-2.4.17.0-1.fc40.aarch64
requires libOpenImageIO.so.2.4()(64bit), but none of the providers can
be installed
DEBUG util.py:461: - package OpenImageIO-devel-2.4.17.0-1.fc40.aarch64
requires OpenImageIO(aarch-64) = 2.4.17.0-1.fc40, but none of the
providers can be installed
DEBUG util.py:461: - conflicting requests
DEBUG util.py:461: - nothing provides
libboost_thread.so.1.81.0()(64bit) needed by OpenImageIO-2.4.17.0-
1.fc40.aarch64
DEBUG util.py:461: - nothing provides libopenvdb.so.10.1()(64bit)
needed by OpenImageIO-2.4.17.0-1.fc40.aarch64
DEBUG util.py:461: Problem 4: package openshadinglanguage-common-
headers-1.12.14.0-9.fc40.noarch requires openshadinglanguage =
1.12.14.0-9.fc40, but none of the providers can be installed
DEBUG util.py:461: - package openshadinglanguage-1.12.14.0-
9.fc40.aarch64 requires liboslquery.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-1.12.14.0-
9.fc40.aarch64 requires liboslexec.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-1.12.14.0-
9.fc40.aarch64 requires liboslcomp.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - conflicting requests
DEBUG util.py:461: - nothing provides
libboost_thread.so.1.81.0()(64bit) needed by openshadinglanguage-libs-
1.12.14.0-9.fc40.aarch64
DEBUG util.py:610: Child return code was: 1
DEBUG util.py:185: kill orphans in chroot /var/lib/mock/f40-build-
48392202-5759785/root
> > Fedora Server as router - Intel CPU
> > - No problems.
> >
> > Fedora Server as router - RaspberryPi
> > - No problems.
> >
> > Fedora Server as file server/imapl server/prometheus - Intel CPU
> > - No problems
> >
> > Fedora KODI media player - Intel CPU
> > - No problems
> >
> > Barry
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
>
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproj
> ect.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
Sérgio M. B.
1 month, 2 weeks
Fedora rawhide compose report: 20180315.n.1 changes
by Fedora Rawhide Report
OLD: Fedora-Rawhide-20180314.n.2
NEW: Fedora-Rawhide-20180315.n.1
===== SUMMARY =====
Added images: 1
Dropped images: 6
Added packages: 3
Dropped packages: 0
Upgraded packages: 83
Downgraded packages: 1
Size of added packages: 6.45 MiB
Size of dropped packages: 0 B
Size of upgraded packages: 2.16 GiB
Size of downgraded packages: 86.24 KiB
Size change of upgraded packages: 175.97 MiB
Size change of downgraded packages: -372.19 KiB
===== ADDED IMAGES =====
Image: Container_Minimal_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180315.n.1.s390x.tar.xz
===== DROPPED IMAGES =====
Image: Modular boot x86_64
Path: Modular/x86_64/iso/Fedora-Modular-netinst-x86_64-Rawhide-20180314.n.2.iso
Image: Modular boot aarch64
Path: Modular/aarch64/iso/Fedora-Modular-netinst-aarch64-Rawhide-20180314.n.2.iso
Image: Modular boot i386
Path: Modular/i386/iso/Fedora-Modular-netinst-i386-Rawhide-20180314.n.2.iso
Image: Modular boot ppc64
Path: Modular/ppc64/iso/Fedora-Modular-netinst-ppc64-Rawhide-20180314.n.2.iso
Image: Modular boot ppc64le
Path: Modular/ppc64le/iso/Fedora-Modular-netinst-ppc64le-Rawhide-20180314.n.2.iso
Image: Modular boot s390x
Path: Modular/s390x/iso/Fedora-Modular-netinst-s390x-Rawhide-20180314.n.2.iso
===== ADDED PACKAGES =====
Package: nodejs-xdg-basedir-3.0.0-2.fc29
Summary: A JavaScript library to work with XDG Base Directory paths
RPMs: nodejs-xdg-basedir
Size: 9.75 KiB
Package: python-flask-htmlmin-1.3.1-1.fc29
Summary: Flask html response minifier
RPMs: python2-flask-htmlmin python3-flask-htmlmin
Size: 24.17 KiB
Package: quentier-0.4.0-0.1.20180301.git8226e31.fc29
Summary: Cross-platform desktop Evernote client
RPMs: quentier
Size: 6.42 MiB
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
Package: CuraEngine-lulzbot-1:2.6.69-1.fc29
Old package: CuraEngine-lulzbot-1:2.6.66-3.fc28
Summary: Engine for processing 3D models into G-code instructions for 3D printers
RPMs: CuraEngine-lulzbot
Size: 3.85 MiB
Size change: 2.05 KiB
Changelog:
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 1:2.6.69-1
- update to 2.6.69
Package: R-BH-1.66.0.1-1.fc29
Old package: R-BH-1.62.0.1-3.fc27
Summary: Boost C++ Header Files for R
RPMs: R-BH-devel
Size: 8.79 MiB
Size change: 801.29 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.62.0.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 1.66.0.1-1
- update to 1.66.0-1
Package: R-BiocGenerics-0.24.0-1.fc29
Old package: R-BiocGenerics-0.22.0-2.fc27
Summary: Generic functions for Bioconductor
RPMs: R-BiocGenerics
Size: 589.92 KiB
Size change: 2.97 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.22.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 0.24.0-1
- update to 0.24.0
Package: R-BiocParallel-1.12.0-1.fc29
Old package: R-BiocParallel-1.10.1-2.fc27
Summary: Bioconductor facilities for parallel evaluation
RPMs: R-BiocParallel
Size: 5.42 MiB
Size change: 4.76 MiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.10.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 1.12.0-1
- update to 1.12.0
Package: R-GenomeInfoDb-1.14.0-1.fc29
Old package: R-GenomeInfoDb-1.12.1-2.fc27
Summary: Utilities for manipulating chromosome and other 'seqname' identifiers
RPMs: R-GenomeInfoDb
Size: 3.41 MiB
Size change: 70.85 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.12.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 1.14.0-1
- update to 1.14.0
Package: R-GenomeInfoDbData-1.0.0-1.fc29
Old package: R-GenomeInfoDbData-0.99.0-2.fc27
Summary: Species and taxonomy ID look up tables used by GenomeInfoDb
RPMs: R-GenomeInfoDbData
Size: 17.13 MiB
Size change: 1.63 MiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.99.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 1.0.0-1
- update to 1.0.0
Package: R-S4Vectors-0.16.0-1.fc29
Old package: R-S4Vectors-0.14.3-3.fc27
Summary: S4 implementation of vectors and lists
RPMs: R-S4Vectors R-S4Vectors-devel
Size: 8.27 MiB
Size change: 5.43 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.14.3-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 0.16.0-1
- update to 0.16.0
Package: R-crayon-1.3.4-1.fc29
Old package: R-crayon-1.3.1-5.fc27
Summary: Colored Terminal Output
RPMs: R-crayon
Size: 708.59 KiB
Size change: 102.98 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.3.1-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 07 2018 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> - 1.3.4-1
- Update to latest version
Package: apr-api-docs-1.6.3-1.fc29
Old package: apr-api-docs-1.5.2-4.fc27
Summary: Apache Portable Runtime API documentation
RPMs: apr-api-docs
Size: 995.30 KiB
Size change: 63.83 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.5.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Mar 15 2018 Bojan Smojver <bojan(a)rexursive.com> 1.6.3-1
- bump up to 1.6.3
Package: audacious-3.9-3.fc29
Old package: audacious-3.9-2.fc28
Summary: Advanced audio player
RPMs: audacious audacious-devel audacious-libs
Size: 4.90 MiB
Size change: 11.70 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 3.9-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: automaton-1.12r1-2.fc29
Old package: automaton-1.12r1-1.fc27
Summary: A Java finite state automata/regular expression library
RPMs: automaton automaton-javadoc
Size: 255.73 KiB
Size change: 472 B
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.12r1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: balsa-2.5.5-1.fc29
Old package: balsa-2.5.3-7.fc28
Summary: Mail Client
RPMs: balsa
Size: 20.51 MiB
Size change: 358.66 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 2.5.3-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Pawel Salek <pawsa0(a)gmail.com> - 2.5.5-1
- Update to upstream balsa-2.5.5
Package: bash-completion-1:2.7-4.fc29
Old package: bash-completion-1:2.7-3.fc28
Summary: Programmable completion for Bash
RPMs: bash-completion
Size: 272.05 KiB
Size change: 72 B
Changelog:
* Wed Mar 14 2018 Siteshwar Vashisht <svashisht(a)redhat.com> - 1:2.7-4
- Do not use $MANPATH directly
Resolves: #1495055
Package: bcm283x-firmware-20180314-1.086a848.fc29
Old package: bcm283x-firmware-20180307-1.7fdcd00.fc29
Summary: Broadcom bcm283x firmware for the Raspberry Pi
RPMs: bcm283x-firmware
Size: 11.07 MiB
Size change: 3.22 KiB
Changelog:
* Wed Mar 14 2018 Peter Robinson <pbrobinson(a)fedoraproject.org> 20180314-1.086a848
- Add support for Raspberry Pi 3+ (Happy Pi day)
Package: berry-1.0.0-6.fc29
Old package: berry-1.0.0-4.fc28
Summary: Modern and light image viewer
RPMs: berry
Size: 9.93 MiB
Size change: 51.45 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.0.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Martin Gansser <martinkg(a)fedoraproject.org> - 1.0.0-6
- Rebuild
Package: bochs-2.6.9-7.fc29
Old package: bochs-2.6.9-6.fc28
Summary: Portable x86 PC emulator
RPMs: bochs bochs-bios bochs-debugger bochs-devel bochs-gdb
Size: 20.35 MiB
Size change: 42.62 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 2.6.9-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: cassandra-3.11.1-3.fc29
Old package: cassandra-3.11.1-3.fc28
Summary: Client utilities for Cassandra
RPMs: cassandra cassandra-java-libs cassandra-javadoc cassandra-parent cassandra-python2-cqlshlib cassandra-server
Size: 66.56 MiB
Size change: -18.66 KiB
Package: claws-mail-3.16.0-1.fc29
Old package: claws-mail-3.15.1-5.fc28
Summary: Email client and news reader based on GTK+
RPMs: claws-mail claws-mail-devel claws-mail-plugins claws-mail-plugins-acpi-notifier claws-mail-plugins-address-keeper claws-mail-plugins-archive claws-mail-plugins-att-remover claws-mail-plugins-attachwarner claws-mail-plugins-bogofilter claws-mail-plugins-bsfilter claws-mail-plugins-clamd claws-mail-plugins-fetchinfo claws-mail-plugins-gdata claws-mail-plugins-libravatar claws-mail-plugins-mailmbox claws-mail-plugins-managesieve claws-mail-plugins-newmail claws-mail-plugins-notification claws-mail-plugins-pdf-viewer claws-mail-plugins-perl claws-mail-plugins-pgp claws-mail-plugins-python claws-mail-plugins-rssyl claws-mail-plugins-smime claws-mail-plugins-spam-report claws-mail-plugins-spamassassin claws-mail-plugins-tnef claws-mail-plugins-vcalendar
Size: 40.32 MiB
Size change: 10.74 MiB
Changelog:
* Tue Jan 09 2018 Michael Schwendt <mschwendt(a)fedoraproject.org>
- texlive is installable again, so set build_manual to 1
- add sed/grep lines to %prep to change DEFAULT_INC_PATH in headers
* Sat Jan 20 2018 Bj��rn Esser <besser82(a)fedoraproject.org> - 3.15.1-6
- Rebuilt for switch to libxcrypt
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 3.15.1-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Tue Mar 13 2018 Michael Schwendt <mschwendt(a)fedoraproject.org> - 3.16.0-1
- Patch for NetworkManager-glib-devel being replaced with libnm / rhbz#1530613
- Patch old DES encrypt() code to use Nettle library, needed for
F28 System Wide Change: Replace glibc's libcrypt with libxcrypt
- Readd and conditionalize scriptlets for dists older than Fedora 28.
- Use %license tag.
- Double escape macros in comments.
- Drop old -geolocation obsoletes tag.
- Upgrade to 3.16.0.
- Patches unnecessary: utils-typo, alertpanel, libical3
Package: cura-lulzbot-1:2.6.69-1.fc29
Old package: cura-lulzbot-1:2.6.66-3.fc28
Summary: 3D printer control software
RPMs: cura-lulzbot
Size: 12.62 MiB
Size change: 2.29 MiB
Changelog:
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 1:2.6.69-1
- update to 2.6.69
Package: curl-7.59.0-2.fc29
Old package: curl-7.59.0-1.fc29
Summary: A utility for getting files from remote servers (FTP, HTTP, and others)
RPMs: curl curl-minimal libcurl libcurl-devel libcurl-minimal
Size: 12.61 MiB
Size change: 2.95 KiB
Changelog:
* Wed Mar 14 2018 Kamil Dudka <kdudka(a)redhat.com> - 7.59.0-2
- ftp: fix typo in recursive callback detection for seeking
Package: dbus-python-1.2.4-13.fc29
Old package: dbus-python-1.2.4-11.fc28
Summary: D-Bus Python Bindings
RPMs: dbus-python-devel python2-dbus python3-dbus
Size: 2.53 MiB
Size change: 24.68 KiB
Changelog:
* Wed Jan 03 2018 Iryna Shcherbina <ishcherb(a)redhat.com> - 1.2.4-12
- Update Python 2 dependency declarations to new packaging standards
(See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3)
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.2.4-13
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: dnssec-trigger-0.15-5.fc29
Old package: dnssec-trigger-0.15-4.fc28
Summary: Tool for dynamic reconfiguration of validating resolver Unbound
RPMs: dnssec-trigger dnssec-trigger-panel
Size: 1.09 MiB
Size change: 2.37 KiB
Changelog:
* Wed Mar 14 2018 Petr Men����k <pemensik(a)redhat.com> - 0.15-5
- Accept NXDOMAIN for NSEC probe (#1555355)
Package: erlang-20.3-1.fc29
Old package: erlang-20.2.4-1.fc29
Summary: General-purpose programming language and runtime environment
RPMs: erlang erlang-asn1 erlang-common_test erlang-compiler erlang-cosEvent erlang-cosEventDomain erlang-cosFileTransfer erlang-cosNotification erlang-cosProperty erlang-cosTime erlang-cosTransactions erlang-crypto erlang-debugger erlang-dialyzer erlang-diameter erlang-doc erlang-edoc erlang-eldap erlang-erl_docgen erlang-erl_interface erlang-erts erlang-et erlang-eunit erlang-examples erlang-hipe erlang-ic erlang-inets erlang-jinterface erlang-kernel erlang-megaco erlang-mnesia erlang-observer erlang-odbc erlang-orber erlang-os_mon erlang-otp_mibs erlang-parsetools erlang-public_key erlang-reltool erlang-runtime_tools erlang-sasl erlang-snmp erlang-ssh erlang-ssl erlang-stdlib erlang-syntax_tools erlang-tools erlang-wx erlang-xmerl
Size: 266.90 MiB
Size change: 140.57 KiB
Changelog:
* Wed Mar 14 2018 Peter Lemenkov <lemenkov(a)gmail.com> - 20.3
- Ver. 20.3
Package: erlang-eper-0.97.3-5.fc29
Old package: erlang-eper-0.97.3-2.fc27
Summary: Erlang Performance and Debugging Tools
RPMs: erlang-eper
Size: 1.35 MiB
Size change: 2.71 KiB
Changelog:
* Wed Jul 26 2017 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.97.3-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Wed Aug 02 2017 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.97.3-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.97.3-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: erlang-gproc-0.7.0-2.fc29
Old package: erlang-gproc-0.7.0-1.fc28
Summary: Extended process registry for Erlang
RPMs: erlang-gproc
Size: 2.86 MiB
Size change: -2.66 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.7.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: erlang-meck-0.8.8-3.fc29
Old package: erlang-meck-0.8.8-2.fc28
Summary: A mocking library for Erlang
RPMs: erlang-meck
Size: 533.60 KiB
Size change: 1.24 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.8.8-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: erlang-stdlib2-0-0.2.20170810git5ccd9b2.fc29
Old package: erlang-stdlib2-0-0.1.20170810git5ccd9b2.fc28
Summary: Erlang stdlib extensions
RPMs: erlang-stdlib2
Size: 798.01 KiB
Size change: 2.21 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0-0.2.20170810git5ccd9b2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: fontconfig-2.13.0-3.fc29
Old package: fontconfig-2.13.0-2.fc29
Summary: Font configuration and customization library
RPMs: fontconfig fontconfig-devel fontconfig-devel-doc
Size: 2.96 MiB
Size change: 1.45 KiB
Changelog:
* Thu Mar 15 2018 Akira TAGOH <tagoh(a)redhat.com> - 2.13.0-3
- Another fix to accept the const names in param.
- Fix locale issue.
Package: ftp-0.17-76.fc29
Old package: ftp-0.17-75.fc28
Summary: The standard UNIX FTP (File Transfer Protocol) client
RPMs: ftp
Size: 484.87 KiB
Size change: 5.49 KiB
Changelog:
* Wed Mar 14 2018 Michal Ruprich <mruprich(a)redhat.com> - 0.17-76
- use distribution LDFLAGS during build (#1548427) - fix by jsynacek
- fixed bogus dates in changelog
Package: gc-7.6.4-3.fc29
Old package: gc-7.6.4-2.fc29
Summary: A garbage collector for C and C++
RPMs: gc gc-devel
Size: 1.58 MiB
Size change: 3.50 KiB
Changelog:
* Wed Mar 14 2018 Rex Dieter <rdieter(a)fedoraproject.org> - 7.6.4-3
- gc: Effectively overrides -fexceptions flag (#1551671)
- move autoreconf to %build
Package: gocomplete-0-0.3.20170908git88e5976.fc29
Old package: gocomplete-0-0.2.20170908git88e5976.fc28
Summary: A tool for bash writing bash completion in Go (Golang)
RPMs: gocomplete golang-github-posener-complete-devel golang-github-posener-complete-unit-test-devel
Size: 5.29 MiB
Size change: 59.92 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0-0.3.20170908git88e5976
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
Package: golang-bazil-fuse-0-0.4.20180310git371fbbd.fc29
Old package: golang-bazil-fuse-0-0.3.20180310git371fbbd.fc29
Summary: Go library for writing FUSE userspace filesystems
RPMs: golang-bazil-fuse-devel
Size: 1.08 MiB
Size change: 552 B
Changelog:
* Wed Mar 07 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180313git371fbbd
- Update with the new Go packaging
- Add doc and examples
- Make devel package arched
* Wed Mar 14 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.4.20180313git371fbbd
- Fix BuildRequires
Package: golang-github-boombuler-barcode-1.0.0-0.fc29
Old package: golang-github-boombuler-barcode-0-0.1.20170922git3cfea5a.fc28
Summary: A barcode creation lib for Go (Golang)
RPMs: golang-github-boombuler-barcode-devel golang-github-boombuler-barcode-unit-test-devel
Size: 227.79 KiB
Size change: 2.26 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0-0.2.20170922git3cfea5a
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Ed Marshall <esm(a)logic.net> - 1.0.0-0
- Fix FTBFS, switch to release version number rather than git SHA.
Package: golang-github-chzyer-test-0-0.5.20180314gita1ea475.fc29
Old package: golang-github-chzyer-test-0-0.4.20180314gita1ea475.fc29
Summary: Golang test utility
RPMs: golang-github-chzyer-test-devel
Size: 12.73 KiB
Size change: 96 B
Changelog:
* Wed Mar 14 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.5.20180314gita1ea475
- Fix BuildRequires
Package: golang-github-denisenkom-go-mssqldb-0-0.1.20180314gitb2a6258.fc29
Old package: golang-github-denisenkom-go-mssqldb-0-0.1.20170919gitc7ee415.fc28
Summary: Microsoft SQL server driver for Go (golang)
RPMs: golang-github-denisenkom-go-mssqldb-devel golang-github-denisenkom-go-mssqldb-unit-test-devel
Size: 500.31 KiB
Size change: 5.52 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0-0.2.20170919gitc7ee415
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Ed Marshall <esm(a)logic.net> - 0-0.1.20180314gitb2a6258
- Update to latest git commit, for Go 1.10 test fixes
Package: golang-github-duosecurity-duo_api_golang-0-0.3.20160627git2b2d787.fc29
Old package: golang-github-duosecurity-duo_api_golang-0-0.1.20160627git2b2d787.fc28
Summary: Duo Security API for strong two-factor authentication
RPMs: golang-github-duosecurity-duo_api_golang-devel golang-github-duosecurity-duo_api_golang-unit-test-devel
Size: 108.10 KiB
Size change: 3.07 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0-0.2.20160627git2b2d787
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Ed Marshall <esm(a)logic.net> - 0-0.3.20160627git2b2d787
- Add patch to fix FTBFS with Go 1.10.
Package: golang-github-jlaffaye-ftp-0-0.3.20180314git4274679.fc29
Old package: golang-github-jlaffaye-ftp-0-0.2.20170927git299b7ff.fc28
Summary: A FTP client package for Go
RPMs: golang-github-jlaffaye-ftp-devel
Dropped RPMs: golang-github-jlaffaye-ftp-unit-test-devel
Size: 21.46 KiB
Size change: -73.02 KiB
Changelog:
* Thu Mar 08 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314git4274679
- Update with the new Go packaging
- Upstream GIT revision 4274679
Package: golang-github-kylelemons-godebug-0-0.3.20180314gitd65d576.fc29
Old package: golang-github-kylelemons-godebug-0-0.2.20170820gitd65d576.fc28
Summary: Debugging helper utilities for Go
RPMs: golang-github-kylelemons-godebug-devel
Dropped RPMs: golang-github-kylelemons-godebug-unit-test-devel
Size: 24.23 KiB
Size change: -101.22 KiB
Changelog:
* Thu Mar 08 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314gitd65d576
- Update with the new Go packaging
Package: golang-github-nwidger-jsoncolor-0-0.4.20180314git75a6de4.fc29
Old package: golang-github-nwidger-jsoncolor-0-0.2.20170215git75a6de4.fc28
Summary: Colorized JSON output for Go
RPMs: golang-github-nwidger-jsoncolor-devel
Size: 12.80 KiB
Size change: 780 B
Changelog:
* Fri Mar 09 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314git75a6de4
- Update with the new Go packaging
* Wed Mar 14 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.4.20180314git75a6de4
- Fix BuildRequires
Package: golang-github-rfjakob-eme-1.1-3.fc29
Old package: golang-github-rfjakob-eme-1.1-2.fc28
Summary: Encrypt-Mix-Encrypt for Go
RPMs: golang-github-rfjakob-eme-devel
Dropped RPMs: golang-github-rfjakob-eme-unit-test-devel
Size: 19.98 KiB
Size change: -96.88 KiB
Changelog:
* Fri Mar 09 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 1.1-3
- Update with the new Go packaging
Package: golang-github-robertkrimen-otto-0-0.4.20180314git6c383dd.fc29
Old package: golang-github-robertkrimen-otto-0-0.2.20171130git3b44b4d.fc28
Summary: A JavaScript interpreter in Golang
RPMs: golang-github-robertkrimen-otto-devel
Dropped RPMs: golang-github-robertkrimen-otto-unit-test-devel
Size: 234.23 KiB
Size change: -463.50 KiB
Changelog:
* Fri Mar 09 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314git6c383dd
- Update with the new Go packaging
- Upstream GIT revision 6c383dd
* Wed Mar 14 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.4.20180314git6c383dd
- Fix BuildRequires
Package: golang-github-xanzy-ssh-agent-0-0.4.20180314gitba9c9e3.fc29
Old package: golang-github-xanzy-ssh-agent-0-0.2.20151215gitba9c9e3.fc28
Summary: Create a ssh-agent on any type of OS from any Go application
RPMs: golang-github-xanzy-ssh-agent-devel
Size: 13.64 KiB
Size change: -1.30 KiB
Changelog:
* Fri Mar 09 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314gitba9c9e3
- Update with the new Go packaging
* Wed Mar 14 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.4.20180314gitba9c9e3
- Fix BuildRequires
Package: golang-github-zyedidia-clipboard-0-0.3.20180314git4611e80.fc29
Old package: golang-github-zyedidia-clipboard-0-0.2.20161226gitadacf41.fc28
Summary: Clipboard for golang
RPMs: golang-github-zyedidia-clipboard-devel
Dropped RPMs: golang-github-zyedidia-clipboard-unit-test-devel
Size: 11.58 KiB
Size change: -59.48 KiB
Changelog:
* Sat Mar 10 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314git4611e80
- Update with the new Go packaging
- Upstream GIT revision 4611e80
Package: golang-github-zyedidia-glob-0-0.3.20180314gitdd4023a.fc29
Old package: golang-github-zyedidia-glob-0-0.2.20170209gitdd4023a.fc28
Summary: A Go package for glob matching
RPMs: golang-github-zyedidia-glob-devel
Dropped RPMs: golang-github-zyedidia-glob-unit-test-devel
Size: 11.11 KiB
Size change: -56.52 KiB
Changelog:
* Sat Mar 10 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314gitdd4023a
- Update with the new Go packaging
Package: golang-github-zyedidia-poller-0-0.3.20180314gitab09682.fc29
Old package: golang-github-zyedidia-poller-0-0.2.20170616gitab09682.fc28
Summary: An epoll(7)-based file-descriptor multiplexer
RPMs: golang-github-zyedidia-poller-devel
Dropped RPMs: golang-github-zyedidia-poller-unit-test-devel
Size: 21.01 KiB
Size change: -82.78 KiB
Changelog:
* Sat Mar 10 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314gitab09682
- Update with the new Go packaging
Package: golang-github-zyedidia-pty-1.1.1-0.2.20180314git3036466.fc29
Old package: golang-github-zyedidia-pty-0-0.1.20180126git3036466.fc28
Summary: PTY interface for Go
RPMs: golang-github-zyedidia-pty-devel
Size: 72.55 KiB
Size change: 56.32 KiB
Changelog:
* Fri Jan 26 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 1.1.1-0.1.20180126git3036466
- Initial package for Fedora
* Sat Mar 10 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 1.1.1-0.2.20180314git3036466
- Update with the new Go packaging
Package: golang-github-zyedidia-tcell-0-0.4.20180314git208b6e8.fc29
Old package: golang-github-zyedidia-tcell-0-0.2.20171129git869faf8.fc28
Summary: Alternate terminal package, similar to termbox
RPMs: golang-github-zyedidia-tcell-devel
Dropped RPMs: golang-github-zyedidia-tcell-unit-test-devel
Size: 83.68 KiB
Size change: -135.34 KiB
Changelog:
* Sat Mar 10 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.3.20180314git208b6e8
- Update with the new Go packaging
- Upstream GIT revision 208b6e8
* Wed Mar 14 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.4.20180314git208b6e8
- Fix BuildRequires
Package: golang-github-zyedidia-terminal-0-0.2.20180314git1760577.fc29
Old package: golang-github-zyedidia-terminal-0-0.1.20180126git1760577.fc29
Summary: Vt10x terminal emulation backend
RPMs: golang-github-zyedidia-terminal-devel
Dropped RPMs: golang-github-zyedidia-terminal-unit-test-devel
Size: 21.83 KiB
Size change: -57.53 KiB
Changelog:
* Fri Mar 09 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.2.20180314git1760577
- Update with the new Go packaging
Package: icecat-52.7.0-1.fc29
Old package: icecat-52.6.0-7.fc29
Summary: GNU version of Firefox browser
RPMs: icecat
Size: 340.42 MiB
Size change: 215.48 KiB
Changelog:
* Sat Mar 10 2018 Antonio Trande <sagitterATfedoraproject.org> - 52.7.0-1
- Update to 52.7.0
Package: ikiwiki-3.20180311-1.fc29
Old package: ikiwiki-3.20180105-3.fc29
Summary: A wiki compiler
RPMs: ikiwiki ikiwiki-w3m
Size: 1.60 MiB
Size change: -1.02 KiB
Changelog:
* Sat Mar 03 2018 Thomas Moschny <thomas.moschny(a)gmx.de> - 3.20180228-1
- Update to 3.20180228.
- Update BRs.
- The rst plugin now uses python3.
* Wed Mar 14 2018 Thomas Moschny <thomas.moschny(a)gmx.de> - 3.20180311-1
- Update to 2.0180311.
Package: jetring-0.26-1.fc29
Old package: jetring-0.25-4.fc28
Summary: GPG keyring maintenance using changesets
RPMs: jetring
Size: 28.18 KiB
Size change: 248 B
Changelog:
* Wed Mar 14 2018 Sandro Mani <manisandro(a)gmail.com> - 0.26-1
- Update to 0.26
Package: kernel-4.16.0-0.rc5.git1.2.fc29
Old package: kernel-4.16.0-0.rc4.git3.1.fc29
Summary: The Linux kernel
RPMs: kernel kernel-bootwrapper kernel-core kernel-cross-headers kernel-debug kernel-debug-core kernel-debug-devel kernel-debug-modules kernel-debug-modules-extra kernel-devel kernel-headers kernel-lpae kernel-lpae-core kernel-lpae-devel kernel-lpae-modules kernel-lpae-modules-extra kernel-modules kernel-modules-extra
Added RPMs: kernel-debug kernel-debug-core kernel-debug-devel kernel-debug-modules kernel-debug-modules-extra
Size: 597.20 MiB
Size change: 113.61 MiB
Changelog:
* Mon Mar 12 2018 Justin M. Forbes <jforbes(a)fedoraproject.org>
- Update efi-lockdown patch with current.
* Mon Mar 12 2018 Jeremy Cline <jeremy(a)jcline.org>
- Disable debugging options.
* Mon Mar 12 2018 Jeremy Cline <jeremy(a)jcline.org> - 4.16.0-0.rc5.git0.1
- Linux v4.16-rc5
* Tue Mar 13 2018 Jeremy Cline <jeremy(a)jcline.org> - 4.16.0-0.rc5.git1.1
- Linux v4.16-rc5-4-gfc6eabbbf8ef
* Wed Mar 14 2018 Jeremy Cline <jeremy(a)jcline.org> - 4.16.0-0.rc5.git1.2
- Fix boot hang on aarch64
Package: libcxx-6.0.0-1.fc29
Old package: libcxx-6.0.0-0.1.rc1.fc28
Summary: C++ standard library targeting C++11
RPMs: libcxx libcxx-devel libcxx-static
Size: 6.30 MiB
Size change: -3.09 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 6.0.0-0.2.rc1
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 6.0.0-1
- 6.0.0 final
Package: libcxxabi-6.0.0-1.fc29
Old package: libcxxabi-6.0.0-0.1.rc1.fc28
Summary: Low level support for a standard C++ library
RPMs: libcxxabi libcxxabi-devel libcxxabi-static
Size: 1.03 MiB
Size change: 5.07 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 6.0.0-0.2.rc1
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 6.0.0-1
- update to 6.0.0 final
Package: libmodulemd-1.1.0-1.fc29
Old package: libmodulemd-1.0.4-2.fc29
Summary: Module metadata manipulation library
RPMs: libmodulemd libmodulemd-devel
Size: 970.66 KiB
Size change: 188.98 KiB
Changelog:
* Wed Mar 14 2018 Stephen Gallagher <sgallagh(a)redhat.com> - 1.1.0-1
- Update to version 1.1.0
- Adds support for handling modulemd-defaults YAML documents
- Adds peek()/dup() routines to all object properties
- Adds Modulemd.Module.dup_nsvc() to retrieve the canonical form of the unique module identifier.
- Adds support for boolean types in the XMD section
- Revert obsoletion of pythonX-modulemd packages for now
Package: libpsm2-10.3.8-5.fc29
Old package: libpsm2-10.3.8-3.fc28
Summary: Intel PSM Libraries
RPMs: libpsm2 libpsm2-compat libpsm2-devel
Size: 262.06 KiB
Size change: 1.32 KiB
Changelog:
* Wed Feb 07 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 10.3.8-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Mar 15 2018 - 10.3.8-5
- Fix partial injection of Fedora build flags.
- Double the sizeof array fdesc to fix a gcc compiling issue.
- Resolves: bz1556062
Package: libslz-1.1.0-6.fc29
Old package: libslz-1.1.0-5.fc28
Summary: StateLess Zip
RPMs: libslz libslz-devel
Size: 460.05 KiB
Size change: 2.98 KiB
Changelog:
* Wed Mar 14 2018 Dridi Boukelmoune <dridi(a)fedoraproject.org> - 1.1.0-6
- BR: gcc after https://fedoraproject.org/wiki/Packaging:C_and_C++ update
Package: libtirpc-1.0.3-0.fc29
Old package: libtirpc-1.0.2-6.rc2.fc29
Summary: Transport Independent RPC Library
RPMs: libtirpc libtirpc-devel
Size: 1.61 MiB
Size change: 1.36 KiB
Changelog:
* Wed Mar 14 2018 Steve Dickson <steved(a)redhat.com> 1.0.2-0
- Update to latest upstream release: libtirpc-1-0-3
Package: lldb-6.0.0-2.fc29
Old package: lldb-6.0.0-1.fc29
Summary: Next generation high-performance debugger
RPMs: lldb lldb-devel python2-lldb
Size: 36.83 MiB
Size change: 286.06 KiB
Changelog:
* Wed Mar 14 2018 Tilmann Scheller <tschelle(a)redhat.com> - 6.0.0-2
- Restore LLDB SB API headers, fixes rhbz#1548758
Package: lollypop-0.9.401-1.fc29
Old package: lollypop-0.9.400-1.fc29
Summary: Music player for GNOME
RPMs: lollypop lollypop-cli lollypop-portal
Size: 704.75 KiB
Size change: 2.93 KiB
Changelog:
* Wed Mar 14 2018 Martin Gansser <martinkg(a)fedoraproject.org> - 0.9.401-1
- Update to 0.9.401
- Cleanup spec file
Package: lulzbot-marlin-firmware-1:1.1.5.71-1.fc29
Old package: lulzbot-marlin-firmware-1:1.1.5.70-2.fc28
Summary: Marlin firmware files for the Lulzbot family of 3D printers
RPMs: lulzbot-marlin-firmware
Size: 1.40 MiB
Size change: -1.82 KiB
Changelog:
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 1:1.1.5.71-1
- update to 1.1.5.71
Package: lyx-2.3.0-1.fc29
Old package: lyx-2.2.3-6.fc28
Summary: WYSIWYM (What You See Is What You Mean) document processor
RPMs: lyx lyx-common lyx-fonts
Size: 70.39 MiB
Size change: 1.84 MiB
Changelog:
* Thu Feb 08 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 2.2.3-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Sun Feb 25 2018 Jos�� Matos <jamatos(a)fedoraproject.org> - 2.3.0-0
- Rebuild for 2.3.0
Package: mongo-c-driver-1.9.3-2.fc29
Old package: mongo-c-driver-1.9.3-1.fc29
Summary: Client library written in C for MongoDB
RPMs: mongo-c-driver mongo-c-driver-devel mongo-c-driver-libs
Size: 9.22 MiB
Size change: 620 B
Changelog:
* Wed Mar 14 2018 Charalampos Stratakis <cstratak(a)redhat.com> - 1.9.3-2
- Fix docs build with Sphinx >= 1.7
Package: nheko-0.2.1-1.fc29
Old package: nheko-0.2.0-1.fc29
Summary: Desktop client for the Matrix protocol
RPMs: nheko
Size: 24.16 MiB
Size change: 97.09 KiB
Changelog:
* Wed Mar 14 2018 Vitaly Zaitsev <vitaly(a)easycoding.org> - 0.2.1-1
- Updated to version 0.2.1.
Package: perl-Hash-Merge-0.300-1.fc29
Old package: perl-Hash-Merge-0.299-2.fc28
Summary: Merges arbitrary deep hashes into a single hash
RPMs: perl-Hash-Merge
Size: 21.98 KiB
Size change: 900 B
Changelog:
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 0.300-1
- update to 0.300
Package: perl-MCE-Shared-1.836-1.fc29
Old package: perl-MCE-Shared-1.835-2.fc28
Summary: MCE extension for sharing data, supporting threads and processes
RPMs: perl-MCE-Shared
Size: 199.69 KiB
Size change: 2.66 KiB
Changelog:
* Wed Mar 14 2018 Paul Howarth <paul(a)city-fan.org> - 1.836-1
- Update to 1.836
- Added chameneos demonstration to MCE::Shared::Condvar
- Load IO::Handle for extra stability, preventing workers loading uniquely
- Load Net::HTTP and Net::HTTPS before spawning if present LWP::UserAgent
See http://www.perlmonks.org/?node_id=1199760
and http://www.perlmonks.org/?node_id=1199891
- Bumped MCE dependency to 1.835
Package: perl-Net-SSLeay-1.85-1.fc29
Old package: perl-Net-SSLeay-1.84-2.fc28
Summary: Perl extension for using OpenSSL
RPMs: perl-Net-SSLeay
Size: 2.39 MiB
Size change: 1.04 KiB
Changelog:
* Wed Mar 14 2018 Paul Howarth <paul(a)city-fan.org> - 1.85-1
- Update to 1.85
- Preparations for transferring maintenace to a new maintainer
- Fixed test failure in t/local/33_x509_create_cert.t for some versions of
OpenSSL
- Fixed free() error that causes "Free to wrong pool ..." message on Windows
Package: php-7.2.4~RC1-1.fc29
Old package: php-7.2.3-1.fc29
Summary: PHP scripting language for creating dynamic web sites
RPMs: php php-bcmath php-cli php-common php-dba php-dbg php-devel php-embedded php-enchant php-fpm php-gd php-gmp php-imap php-interbase php-intl php-json php-ldap php-mbstring php-mysqlnd php-odbc php-opcache php-pdo php-pdo-dblib php-pgsql php-process php-pspell php-recode php-snmp php-soap php-sodium php-tidy php-xml php-xmlrpc
Size: 133.15 MiB
Size change: 89.02 KiB
Changelog:
* Tue Mar 13 2018 Remi Collet <remi(a)remirepo.net> - 7.2.4~RC1-1
- update to 7.2.4RC1
Package: php-facedetect-1.2.0-0.3.20180306gitc717941.fc29
Old package: php-facedetect-1.2.0-0.1.20180305git263435f.fc29
Summary: PHP extension to access the OpenCV library
RPMs: php-facedetect
Size: 152.30 KiB
Size change: 1.37 KiB
Changelog:
* Thu Mar 15 2018 S��rgio Basto <sergio(a)serjux.com> - 1.2.0-0.2.20180306gitc717941
- Add last commit
* Thu Mar 15 2018 S��rgio Basto <sergio(a)serjux.com> - 1.2.0-0.3.20180306gitc717941
- Fix the License tag
Package: php-pear-DB-1.9.2-6.fc29
Old package: php-pear-DB-1.9.2-4.fc27
Summary: PEAR: Database Abstraction Layer
RPMs: php-pear-DB
Size: 108.61 KiB
Size change: -982 B
Changelog:
* Fri Feb 09 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.9.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Mar 15 2018 Remi Collet <remi(a)fedoraproject.org> - 1.9.2-6
- fix condition in test suite, FTBFS #1556118
- fix count usage for PHP 7.2
Package: podman-0.3.3-1.dev.gitbc358eb.fc29
Old package: podman-0.3.2-1.gitf79a39a.fc29
Summary: Manage Pods, Containers and Container Images
RPMs: podman
Size: 45.22 MiB
Size change: 98.71 KiB
Changelog:
* Fri Mar 09 2018 baude <bbaude(a)redhat.com> - 0.3.2-1.gitf79a39a
- Release 0.3.2-1
* Wed Mar 14 2018 Lokesh Mandvekar <lsm5(a)fedoraproject.org> - 0.3.3-1.dev.gitbc358eb
- built podman commit bc358eb
- built conmon from cri-o commit 712f3b8
Package: pungi-4.1.22-9.fc29
Old package: pungi-4.1.22-8.fc29
Summary: Distribution compose tool
RPMs: pungi pungi-legacy pungi-utils python2-pungi python3-pungi
Size: 1.34 MiB
Size change: 2.60 KiB
Changelog:
* Wed Mar 14 2018 Lubom��r Sedl���� <lsedlar(a)redhat.com> - 4.1.22-9
- Allow empty modular variants
- Add option to disable multilib
Package: pytest-3.4.2-1.fc29
Old package: pytest-3.2.3-4.fc28
Summary: Simple powerful testing with Python
RPMs: python2-pytest python3-pytest
Size: 2.60 MiB
Size change: 129.05 KiB
Changelog:
* Wed Mar 14 2018 Charalampos Stratakis <cstratak(a)redhat.com> - 3.4.2-1
- Update to 3.4.2
Package: python-astropy-2.0.5-1.fc29
Old package: python-astropy-2.0.4-3.fc29
Summary: A Community Python Library for Astronomy
RPMs: astropy-tools python2-astropy python2-astropy-doc python3-astropy python3-astropy-doc
Size: 246.05 MiB
Size change: 207.87 KiB
Changelog:
* Wed Mar 14 2018 Christian Dersch <lupinix(a)mailbox.org> - 2.0.5-1
- new version
- enabled fixed tests
Package: python-freetype-1.2.1-1.fc29
Old package: python-freetype-1.0.2-4.fc27
Summary: Freetype python bindings
RPMs: python2-freetype python3-freetype
Size: 343.66 KiB
Size change: 27.33 KiB
Changelog:
* Fri Sep 01 2017 Parag Nemade <pnemade AT redhat DOT com> - 1.1-1
- Update to 1.1 version
* Fri Feb 09 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Tue Feb 27 2018 Parag Nemade <pnemade AT redhat DOT com> - 1.2.1-1
- Update to 1.2.1 version (#1545641)
- Upstream keeps mistaking for generating egg-info, I have to adjust here
Package: python-uranium-lulzbot-2.6.69-1.fc29
Old package: python-uranium-lulzbot-2.6.66-2.fc28
Summary: A Python framework for building desktop applications (Lulzbot fork)
RPMs: python-uranium-lulzbot-doc python3-uranium-lulzbot
Size: 1.28 MiB
Size change: -88 B
Changelog:
* Wed Mar 14 2018 Tom Callaway <spot(a)fedoraproject.org> - 2.6.69-1
- update to 2.6.69
Package: quassel-irssi-0-8.20171203git079be66.fc29
Old package: quassel-irssi-0-7.20171203git079be66.fc28
Summary: An irssi plugin to connect to quassel core
RPMs: quassel-irssi
Size: 280.67 KiB
Size change: 2.45 KiB
Changelog:
* Fri Feb 09 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 0-8.20171203git079be66
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
- Disable cast-function-type warning to fix build. (#1556306).
Package: rawtherapee-5.4-0.2.rc3.fc29
Old package: rawtherapee-5.4-0.1.rc2.fc29
Summary: Raw image processing software
RPMs: rawtherapee
Size: 135.33 MiB
Size change: 38.66 MiB
Changelog:
* Wed Mar 14 2018 Mattia Verga <mattia.verga(a)email.it> - 5.4-0.2.rc3
- Update to 5.4RC3
Package: redir-2.2.1-20.fc29
Old package: redir-2.2.1-18.fc27
Summary: Redirect TCP connections
RPMs: redir
Size: 232.94 KiB
Size change: 4.76 KiB
Changelog:
* Fri Feb 09 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 2.2.1-19
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Mar 15 2018 Itamar Reis Peixoto <itamar(a)ispbrasil.com.br> - 2.2.1-20
- add gcc into buildrequires
- disable tcp_wrappers
Package: sanlock-3.6.0-4.fc29
Old package: sanlock-3.6.0-2.fc28
Summary: A shared storage lock manager
RPMs: python2-sanlock sanlk-reset sanlock sanlock-devel sanlock-lib
Size: 1.75 MiB
Size change: 4.05 KiB
Changelog:
* Wed Mar 14 2018 David Teigland <teigland(a)redhat.com> - 3.6.0-3
- rebuild with set_build_flags
* Wed Mar 14 2018 David Teigland <teigland(a)redhat.com> - 3.6.0-4
- change makefile flags
Package: stratisd-0.5.0-2.fc29
Old package: stratisd-0.5.0-1.fc29
Summary: Daemon that manages block devices to create filesystems
RPMs: stratisd
Size: 7.05 MiB
Size change: 452.41 KiB
Changelog:
* Tue Mar 13 2018 Andy Grover <agrover(a)redhat.com> - 0.5.0-2
- Add stratisd manpage
Package: tiptop-2.3.1-7.fc29
Old package: tiptop-2.3.1-6.fc28
Summary: Performance monitoring tool based on hardware counters
RPMs: tiptop
Size: 430.29 KiB
Size change: 1.27 KiB
Changelog:
* Wed Mar 14 2018 Dridi Boukelmoune <dridi(a)fedoraproject.org> - 2.3.1-7
- BR: gcc after https://fedoraproject.org/wiki/Packaging:C_and_C++ update
Package: vmod-querystring-1.0.3-3.fc29
Old package: vmod-querystring-1.0.3-1.fc28
Summary: QueryString module for Varnish Cache
RPMs: vmod-querystring
Size: 153.86 KiB
Size change: 3.41 KiB
Changelog:
* Fri Feb 09 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.0.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Mar 15 2018 Dridi Boukelmoune <dridi.boukelmoune(a)gmail.com> - 1.0.3-3
- Explicit python requirements (#1556533)
===== DOWNGRADED PACKAGES =====
Package: golang-github-yuin-gopher-lua-0-0.1.20180314git7d7bc87.fc29
Old package: golang-github-yuin-gopher-lua-0-0.2.20171031git609c9cd.fc28
Summary: GopherLua: VM and compiler for Lua in Go
RPMs: golang-github-yuin-gopher-lua-devel
Dropped RPMs: golang-github-yuin-gopher-lua-unit-test-devel
Size: 86.24 KiB
Size change: -372.19 KiB
Changelog:
* Fri Mar 09 2018 Robert-Andr�� Mauchin <zebob.m(a)gmail.com> - 0-0.1.20180314git7d7bc87
- Update with the new Go packaging
- Upstream GIT revision 7d7bc87
6 years, 1 month
Re: [Modularity]: Service levels and EOL expectations?
by Langdon White
On Mon, Aug 7, 2017 at 3:59 PM Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
> On Mon, Aug 07, 2017 at 02:10:23PM -0400, Stephen John Smoogen wrote:
> > I still don't see how this is going to work with a tree of Service Levels
> > and Lifetimes. Any module can not give a SL greater than the lowest SL
> and
> > the shortest lifetime that any package in it is going to agree to. [EG
> if I
> > am packaging up a wordpress module and glibc is on a 18 month lifetime
> but
> > openssl is meh upstream always.. then unless I am going to maintain
> openssl
> > myself with its own fork... my module is going to be 'meh upstream
> always'.
> > If my module pulls in enough stuff to make it work, I am going to be
> > dealing with the need of a lawyer to figure out which SL's and lifetimes
> > are binding and what ones are not.
>
> Yeah, that would get crazy fast. The 6 month granularity proposal
> should help *some*, and we should probably go into this carefully.
>
> For packages, the default is to have fNN branches with the implied 13
> month lifecycle and 6 month branch/update window. (Which means that
> even nearing the end of the 13 month cycle, there's an overlapping
> cycle going half a year longer.)
>
> The Arbitrary Branching proposal suggests not* do this for f28
> *automatically (but still allow it). Maybe (at first at least) we need
> to say that if packagers want to do *other* cycles, they need to give
> at least this "there's a version with an EOL at least 7 months off, and
> if you hit it right there's a 13 month window" service level. (That
> could be fulfilled by "there's one version that is expected to
> continually update in a compatible way".)
>
> Packagers who don't want to deal with all this could just make the
> "f28" branch, and packagers who instead want to do something else
> longer or additional could.*
>
> Then, we could have an opt-in process (FESCo approval?) for packages
> where the upstream changes too fast to support that. (These packages
> are presumably problematic in Fedora currently _anyway_.)
>
>
> * And "longer" sounds like more work, but in many cases it shouldn't
> be. I maintain couple of small "leaf" utility programs which are
> unlikely to change in a significantly incompatible way, and rather than
> maintaining them across "rawhide, f29, f28, f27, el7" I'd like to
> maintain just "devel" and "2.stable".
>
> But there's _definitely_ a lot still to work out here!
>
> --
> Matthew Miller
> <mattdm(a)fedoraproject.org>
> Fedora Project Leader
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
I guess I am not sure how this is different with modules than with Fedora
today. We promise a 13 month lifecycle on openssl (and everything else)
already. I think the difference here is only that the "position" is
explicit. However, this is not the "real" point to my reply.
I agree it is true that the lifecycle of a given *binary* is locked to the
lifecycle of the module binaries it depends on. However. this does not
necessarily mean that a *stream* is locked to the those lifecycles. In
other words, wordpress doesn't expose glibc or openssl APIs to its
consumers (to my knowledge ;) ). As a result, it is perfectly valid for the
wordpress-4 stream to be built against base-runtime-f26 (brt) or
base-runtime-f27 or both. If the lifecycle of base-runtime-f26 runs out,
that doesn't mean wordpress-4's lifecycle has run out, it just means that
the user must upgrade the base-runtime stream but their application that
relies on the wordpress-4 API will continue to operate unchanged.
I am not saying that updating a brt is not disruptive, but it should not
require code changes to my-wp-app just a replacement of the underlying
components. However, the disruption is just "dnf module enable brt-f27 &&
dnf update and reboot. You may, as a user, actually get new binaries in the
wordpress-4-on-base-runtime-f27 configuration but the wordpress-4 is built
from the same sources and, while not strictly the "same," for 99% of cases
they will be.
As we are able to increase the bundling of components, the 99% continues to
add 9s after the decimal. At present, we must consume the openssl-1.1
branch in brt/shared-userspace because dnf/rpm can't tell that the binaries
provided by different modules are functionally the same. However, as we
improve that or find other methods around this problem (private
namespacing, containers, rpathing, etc), we could have the openssl-1.1
sources in dist-git be included in multiple modules. When the openssl
maintainer elects to add the openssl-1.2 stream, wordpress-4 could decide
if it is appropriately backwards compatible for their use case and consume
it (by changing their modulemd to point to the new stream).
Langdon
6 years, 8 months
Re: [Modularity] A proposal for stream naming
by Petr Šabata
On Thu, Jun 29, 2017 at 11:07:10AM -0400, Matthew Miller wrote:
> On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:
> > > * Modules which correspond primarily to a single application or
> > > versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
> > > use a stream label corresponding to the major version of that software
> > > (e.g. 2.4 or 8)
> > So if I'm reading this correctly, you're proposing Fedora should
> > forbid packagers from creating alternative streams for the same
> > major release of such software? I can imagine different variants
> > of httpd 2.4, built with different compile time options, bundling
> > different components, having different module metadata and such.
>
> I think alternate versions are okay, but those should come after a
> primary version -- there should be *at least* this and then there could
> be others.
Okay. Then it needs to be worded differently.
> In thinking a little further, I think there are three basic bits of
> metadata that need to be easily visible per-stream. Whether it goes
> into the stream label or into other metadata is an implementation
> detail. They are:
>
> * major identifier (in the case of modules with a primary piece of
> software, probably the major version of that software)
> * lifecycle / eol identifier
> * extra tags describing alternate options
>
> So, for example:
>
>
> nodejs 8:e1912 (or maybe 8:e1912:main, but I don't like that)
> nodejs 8:e1806:turbocharged
> nodejs 8:e1912:lite
> httpd 24:stable
> httpd 26:latest
> httpd 24:e1812:spdypatches
EOL's not part of modulemd today for the reasons I mentioned
in my previous email (we don't know if that's the way to go)
but can be added if we finally make that decision.
The extra tags are meant to be part of the stream name today.
The intention was to have stream names more descriptive and
less version-y. Splitting streams into main package versions
and some additional tags would require some changes to how we
handle dist-git-branch-name-to-modulemd-fields mapping.
> > > * Such modules MAY additionally have a "latest" stream, which would be
> > > "rolling release" of the latest stable version (as opposed to master,
> > > which corresponds to rawhide and may be unstable).
> > Sounds like the no-more-alphas Rawhide. Such "latest" streams
> > would drop major changes/rebases on the end users' systems.
> > It makes sense to have this, especially for developers, but
> > we should warn people that it's not the best choice for stable
> > systems and that... it will eat their babies ;)
>
> No, this should definitely not eat babies. (Even Rawhide doesn't do
> that anymore. Usually.) And while automatic gating would be fine, it
> wouldn't need to be.
Given the response above it appears you understand streams
somewhat differently. Until now we've been operating with
the assumption (and everything is coded that way) that streams
map directly to branch names. If you have a "latest" stream,
you develop it in a branch called "latest". If a user consumes
this stream, their automatically get breaking changes because
the "latest stable version" means different things at different
times. Hence the comparison to Rawhide.
And I knew you would respond to the babies bit ;)
> > There are still some open questions regarding EOLs.
> >
> > For instance:
> >
> > Are they bound to the artifact or could that depend on the
> > context? Like "this module will go EOL next year for standard
> > Fedora and nobody will care to make it work with the latest
> > Platform but we'll still support it in the context of this LTS
> > spin / derived distro / whatnot".
>
> If this is a thing, modularity hasn't really succeeded.
I don't know how to respond to this.
> > Can EOL be extended for already released artifacts and if so, do
> > we need to issue an update to let users know through refreshing
> > their metadata?
>
> This is partly why I described EOL as "EOL no earlier than" (thanks to
> Langdon). I think the best thing to do in the case of a long extension
> would be to create a new branch/stream with the new EOL. That's part of
> why I think modules need to carry their own succession information,
> too.
Making people switch between update streams if the content they
already consume becomes supported for longer doesn't feel like
the best UX decision. EOL shouldn't be tied to stream names.
> > Answers to these questions help us decide whether EOL metadata
> > should be bundled with the module, inside modulemd in the
> > repodata, or whether it belongs in an external system such
> > as PDC.
>
> Right. :)
>
>
> > > * A "latest" rolling stream (As above, this would be separate from
> > > "rawhide", as "latest stable", but could update frequently and
> > > arbitrarily.)
> > By the way, should rawhide streams be called rawhide or would
> > master be fine? Stream names come directly from dist-git branch
> > names but of course there could be a hardcoded exception in
> > MBS that does s/master/rawhide/.
>
> There's two big things here. First, it absolutely shouldn't be rawhide.
> That's the same as having f26 or f27 branches: tied to a particular
> base.
>
> Second, though, if we have all the various different variants per
> stream as you describe above, does it even make sense to _have_ a
> master branch? Which variants would it be the master _for_? This might
> suggest that long-lived and very distinct streams should actually have
> a different _name_ and live in a different repo in dist-git, with
> streams in the same repo required to be closely linked in some way.
>
> I'm not sure I like that, though, and it seems very contrary to the
> current design. I guess one option would be for master to automatically
> correspond to "latest major version, rolling release", but that
> seems not as helpful as being explicit. Maybe "master" should just
> contain a readme describing the various branches.
Works for me. Right now we use it for random development but
that's because we're just starting with all this.
> > > * One or more streams corresponding to "end of life no earlier than",
> > > in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for
> > > 'until'? Or "fYYMM" for 'fedora' — which might make sense if we get
> > > to my dream of mixing and matching with CentOS modules....)
> > See my EOL-related points above. Plus this would be ugly :P
>
> Uglier than a bunch of random names with no semantic relation? I'm not
> so sure!
>
> > > Additionally and for all of our sanity, I suggest:
> > > * Valid module end-of-life dates are always either June or December,
> > > corresponding to the Fedora schedule of early May / late October
> > > base releases. So, f1806 or f1812, but not f1810 or f1901.
> > Sounds like a valid recommendation rather than a necessary rule.
>
> I'm gonna argue for rule. As a user, a situation where modules are
> arbitrarily EOLing every day seems nightmarish.
>
> [And I'm going to reply to the second half of this in a separate
> message.]
Ok :)
P
6 years, 9 months
Re: Fork a 119MB pagure project to updating monitoring?
by Michal Konecny
On 26/03/19 20:16, Jeremy Cline wrote:
> On 3/26/19 5:36 AM, Pierre-Yves Chibon wrote:
>> On Tue, Mar 26, 2019 at 09:37:26AM +0100, Michal Konecny wrote:
>>>
>>>
>>> On 25/03/19 21:23, Jeremy Cline wrote:
>>>> On 3/25/19 1:55 PM, Jason L Tibbitts III wrote:
>>>>>>>>>> "KF" == Kevin Fenzi <kevin(a)scrye.com> writes:
>>>>>
>>>>> KF> Well, I find it unfortunate, does that count? :)
>>>>>
>>>>> It is unfortunate, but note that it's unfortunate simply because
>>>>> of our
>>>>> procedures. Certainly it would be nice if the functionality for
>>>>> making
>>>>> new branches and changing monitoring and some bugzilla settings were
>>>>> integrated directly into src.fp.o; I won't argue against that.
>>>>> However,
>>>>> that doesn't mean that changing those settings couldn't be
>>>>> accomplished
>>>>> via some means other than a PR.
>>>>>
>>>>> Possibilities I can think of include:
>>>>>
>>>>> * Doing this via tickets in a manner similar to how branches are
>>>>> requested. This would require teaching the ticket processing
>>>>> tools
>>>>> how to perform the operation, and writing some tool to submit the
>>>>> request. Kind of a lot of overhead for a rare operation.
>>>>>
>>>>> * Just storing this information in the package repository. I've
>>>>> never
>>>>> understood why the system can't just extract this information
>>>>> from
>>>>> git. I suspect there must be some reason related to security or
>>>>> resources consumption which prevents services from having a
>>>>> shallow
>>>>> git clone around from which to grab information like this, but
>>>>> I'm not
>>>>> sure.
>>>>>
>>>>
>>>> This is how it _should_ work. I just looked at the actual
>>>> implementation
>>>> and hotness is doing an HTTP GET to the scm-requests repository. It
>>>> makes no sense, each repo should have a "monitoring" file or
>>>> something.
>>>> From the perspective of hotness, nothing changes. I have no idea
>>>> why it
>>>> was put in a central repository.
>>> I started to maintain the-new-hotness few months ago, so I don't
>>> know why
>>> there is
>>> some central repository. I agree with Jeremy that the best option is
>>> to have
>>> monitoring
>>> information directly in package repository.
>>
>> The original idea, I believe, was to allow for the file to different
>> per branch
>> without breaking the one branch for all releases that many packager
>> like.
>
> That doesn't make sense to me. Are you saying people might want
> different files per branch, but also only have one branch in their dist-
> git? Or is this only about the modularity/stream branching thing?
>
>> With modularity and stream branching, the ability to say: "I want PR
>> filled for
>> this version to this branch and for that version to that branch"
>> would be neat,
>> but this means having per-branch information that the-new-hotness
>> will then
>> access and act upon.
> That shouldn't require any configuration at all. hotness knows the new
> version, and can inspect the branches in dist-git. If the project is
> marked as following semantic versioning in release-monitoring.org, for
> example, it can automatically make PRs against any branch with the same
> X release. The fallback is to always make a PR against master and let
> the packager cherry-pick as they like.
>
>> Having this outside of the dist-git repo was meant to make it easier
>> to tweak
>> this file and have it diverge without having the different dist-git
>> branches
>> diverge.
>
> I think having it outside the repo makes it harder to use in every way.
> I used to maintained hotness and release-monitoring.org and if you sat
> me down and told me to turn on monitoring now that pkgdb is gone, I
> probably wouldn't be able to do it in any reasonable amount of time. The
> packager experience in this regard went from moderately difficult (you
> have to know to poke in pkgdb) to downright horrendous.
Speaking about this, I should take these packages from you to ease your
burden. :-)
>
> - Jeremy
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
5 years