Fedora 32 System-Wide Change proposal: Adopting sysusers.d format

2020-01-02 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format

== Summary ==
Files in sysusers.d format will be used to declare systems users so it
will be possible to introspect system users. Users will still be
created using old-style useradd calls.

== Owner ==
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in waw pl

== Detailed Description ==

Many packages define their own user. Right now, those users are
created in %pre by calling getent, useradd, and groupadd
([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation
guidelines]). This will be changed to define users in the
[https://www.freedesktop.org/software/systemd/man/sysusers.d.html
sysusers.d format]. A macro will be provided to generate a %pre
scriptlet that will call useradd and groupadd similarly to the
scriptlets that are currently required by the packaging guidelines.

In this proposal, systemd-sysusers will not be used to create the
user. Using the sysusers.d format makes it easy to switch to
systemd-sysusers as the implementation, and to experiment with
different way to actually create the users based on the declarative
syntax.

This approach is heavily based on OpenSUSE's
([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
guidelines]), but does not use separate rpm packages. I think using a
%pre macro is good enough.

== Benefit to Fedora ==

System users are declared by packages using a uniform syntax.

The scriptlet part is standardized. Current implementation of creating
users and groups is not changed, but may be switched easily in the
future. For example, for container images, the macro may be replaced
by a noop implementation, and the users created externally without
installing the user creation tools in the container.

Admins may easily introspect the system user list and which packages
require users.

Admins may easily override definitions of system users by providing
appropriate sysusers.d files with higher priority.

The difference between Fedora and other distros like OpenSUSE is reduced.

== Scope ==
* Proposal owners:
** provide the macro and any helper tools
** submit a proposal to FPC
** convert a subset of packages

* Other developers:
** FPC: review (and accept ;)) the guidelines changes
** other maintainers: convert other packages

* Release engineering: n/a

* Policies and guidelines: a pull request will be submitted

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

== Upgrade/compatibility impact ==
None. This change should be backwards and forwards compatible, i.e.
unconverted packages can be still installed on new systems, and
converted packages can be installed on older systems.

== How To Test ==
This change should be mostly invisible to users. During installation,
users should be created as appropriate before packages are installed.
For packages that carry files owned by the user, check that the files
are created with appropriate ownership by rpm.

== User Experience ==
systemd-analyze cat-config sysusers.d/
shows the definitions of system users (incl. local overrides).

== Dependencies ==
N/A

== Contingency Plan ==

* Contingency mechanism: Revert to previous mechanism. This will
require a revert of changes to the spec file and a rebuild of the
package.

* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
TBD.

== Release Notes ==
Not needed.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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.fedoraproject.org


Fedora 32 System-Wide Change proposal: Golang 1.14

2020-01-02 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/golang1.14

== Summary ==
Rebase of Golang package to upcoming version 1.14 in Fedora 32,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time of the mass rebuild).

== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]]
* Email: jca...@redhat.com

== Detailed Description ==

Rebase of Golang package to upcoming version 1.14 in Fedora 32. Golang
1.14 is schedule to be released in Feb 2020.
Due to current nature and state of Go packages, rebuild of dependent
package will be required to pick up the changes.

== Benefit to Fedora ==

Staying closely behind upstream by providing latest release of golang,
which includes performance improvements and improvements in support
for currently supported platforms among other bug fixes and new
features. For complete list of changes see upstream change notes at
https://tip.golang.org/doc/go1.14 . In result Fedora will be providing
solid development platform for Go language.

== Scope ==
* Proposal owners: Rebase golang package in f32, help with resolving
possible issues found during package rebuilds.

* Other developers: Fix possible issues, with help from golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking ticket
https://pagure.io/releng/issue/9136
* Policies and guidelines: N/A
* Trademark approval: N/A

== Upgrade/compatibility impact ==
None

== How To Test ==
;0.
:a)Install golang 1.14 from rawhide and use it to build your
application(s)/package(s).
:b)Scratch build against rawhide.
;1.
:Your application/package built using golang 1.14 should work as expected.

== User Experience ==
None

== Dependencies ==

dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'


Omitted due to the number of packages listed ~1100.


Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.

== Contingency Plan ==
* Contingency mechanism:Reverting to  golang version 1.13.X if
significatnt issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No

== Documentation ==
https://tip.golang.org/doc/go1.14


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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.fedoraproject.org


Fedora 32 System-Wide Change proposal: Systemd presets for user units

2020-01-02 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units

== Summary ==

System units are managed through presets
[https://fedoraproject.org/wiki/Features/PackagePresets since F18] and
by policy, presets are carried by the fedora-release package. This
policy is now extended to user units.

== Owner ==
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in waw pl

== Detailed Description ==

The preset mechanism for user units was already in place, but we were
missing the actual preset files, and the default was "enable *"
instead of "disable *" as for system services.

Systemd will now provide a
/usr/lib/systemd/user-preset/99-default-disable.preset that marks user
services as disabled by default. Any user services which should be
enabled will be to get an appropriate preset in
/usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific
file. Most packages already call into the preset mechanism, but those
which don't will be adjusted to do that.

This is essentially a fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good
reason to treat user services different than system services in this
regard. On the systemd side this change is very simple, but all
packages that provide user units need to be reviewed to check if they
are enabled after the change if appropriate.

== Benefit to Fedora ==

User and system services are handled in the same way.

Local configuration may be used to override which services should be
enabled after upgrade. In particular, "local" in this context may mean
"per-spin" or "per-user".

== Scope ==
* Proposal owners:
** review all packages that provide user services in Fedora and submit
PRs when changes are needed
** add a new presets file to the fedora-release package for user units
** submit a proposal to FPC to update the guidelines (essentially to
say "... and the same for user services.").

* Other developers:
** FPC: review (and accept ;)) the guidelines changes
** other maintainers: verify that units in their packages are enabled
or not as appropriate after package installation

* Release engineering: n/a

* Policies and guidelines: a pull request will be submitted

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

== Upgrade/compatibility impact ==
Should not be user visible. Some units which are are currently enabled
by mistake will not be enabled anymore on new installations.

== How To Test ==
Install a new system (or uninstall and reinstall some packages).
Verify that the appropriate units are enabled for the user session.

== User Experience ==
N/A

== Dependencies ==
N/A

== Contingency Plan ==

* Contingency mechanism: Revert the changes.

* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
A pull request for the packaging guidelines will be submitted.

== Release Notes ==
Not needed.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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.fedoraproject.org


Fedora 32 System-Wide Change proposal: GCC10

2020-01-02 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/GCC10

== Summary ==
Switch GCC in Fedora 32 to 10.x.y, rebuild all packages with it, or
optionally rebuild just some packages with it and rebuild all packages
only in Fedora 33.

== Owner ==
* Name: [[User:Jakub|Jakub Jelínek]]
* Email: ja...@redhat.com

== Detailed Description ==

GCC 10 is currently in stage3, switching to stage4 in January, at
which point it will be in a prerelease state with only regression
bugfixes and documentation fixes allowed. The release will happen
probably in the middle of April. rpms will be built in early January,
but Jeff Law has been testing x86_64 Fedora test mass rebuilds with
GCC 10 snapshots for a while.


== Benefit to Fedora ==

See http://gcc.gnu.org/gcc-10/changes.html for the list of changes.

== Scope ==
* Proposal owners:
Prepare rpms for the new compiler, push them into rawhide, watch
voluntary rebuilds, fix bugs as they are reported, watch fallout from
mass rebuild.

* Other developers: N/A (not a System Wide Change)
Adjust for what will be written in
https://gcc.gnu.org/gcc-10/porting_to.html , fix bugs in packages that
will show up after rebuild or report if there are bugs on the compiler
side.

* Release engineering: Perform a mass rebuild, which will be needed
for the LTO System Wide change too.

* Policies and guidelines: N/A (not a System Wide Change)
I don't think so, this is a usual system compiler update that is being
done every year.  I think we have skipped GCC 4.2, so in Fedora this
is likely the 15th such System Wide change.
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
No impact

== How To Test ==
GCC has its own testsuite, which is run during the package build, plus
many other packages with automated tests also help to test the new
gcc.

== User Experience ==
Users will be able to see compiled code improvements and use the newly
added features.
Developers will notice a newer compiler, and might need to adjust
their codebases acording to http://gcc.gnu.org/gcc-10/porting_to.html,
or, if they detect a GCC bug, report it.

== Dependencies ==
libtool, annobin, gcc-python-plugin depend on exact gcc version, those
need to be rebuilt.

== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in
preparing self-contained testcases to speed up analysis and fixing the
bugs.  Don't have time to debug issues in 12000+ packages, especially
when in many cases it could be caused by undefined code in the
packages etc.  I don't expect we'll have to fall back to the older
gcc, we've never had to do it in the past,
but worst case we can mass rebuild everything with older gcc again.
Jeff Law has performed test mass rebuild on x86_64.

* Contingency mechanism: (What to do?  Who will do it?) Revert to
older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

== Documentation ==
http://gcc.gnu.org/gcc-10/

== Release Notes ==
Fedora 32 comes with GCC 10.1 as primary compiler, see
http://gcc.gnu.org/gcc-10/changes.html for user visible changes in it.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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.fedoraproject.org


Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction

2020-01-02 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transaction

== Summary ==

Scriptlets to restart each service that should be restarted in each
rpm package will be replaced by a declaration in the unit file and an
rpm transaction trigger that fires at the end and restarts all
services.

== Owner ==
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in waw pl


== Detailed Description ==

Currently, when packages containing systemd services are upgraded,
they are restarted through %post scriptlets in each package. In other
words, the scriptlets specify which services should be restarted and
actually run the command to restart the service. An alternative
mechanism will be provided, whereby the unit file contains a setting
which specifies that the service should be restarted on upgrade, and a
%transfiletrigger in the systemd package will restart all services
marked so in upgraded packages at the end of transaction.

To mark a services as "restart on upgrade" the unit file should
contain an option to mark it so. This can be either in the main
.service file, or e.g. in a drop-in file in
/usr/lib/systemd/system/.service.d/needs-restart.conf.
The exact name of the option should be something like
X-restart-on-upgrade=true|false. I'll take the proposal
for discussion in systemd upstream, since this is something that could
be used across distributions, and then the "X-" prefix could be
dropped and/or the name changed.

== Benefit to Fedora ==

Which services should be restarted is specified declaratively and the
number of scriptlets is reduced.

Admins may easily override this by providing appropriate drop-ins of
their own of higher priority.

Services are restarted after the transaction is finished, all
libraries have been upgraded, and systemd configuration reloaded. This
solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a
more general problem: a service may be restarted before any of its
dependencies (files and static content and whatnot) have been
upgraded, and while some contents from the old rpm are still on disk.
Restarting after all packages have been upgraded avoids this issue.

In the future, restarting of services shall also be extended to user
managers (i.e. to restart all user services after the packages
providing those services have been upgraded). This is not part of this
proposal, but moving the information what to restart into systemd
units makes this much easier.

== Scope ==
* Proposal owners:
** implement the relevant bits in the systemd package
** submit a proposal to FPC
** convert a subset of packages

* Other developers:
** FPC: review (and accept ;)) the guidelines changes
** other maintainers: convert other packages

* Release engineering: n/a

* Policies and guidelines: a pull request will be submitted

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

== Upgrade/compatibility impact ==
This change should be backwards compatible, i.e. unconverted packages
can be still installed on new systems, and services will be restarted
on upgrade like before. Converted packages may be installed on older
systems but will not get restarted on upgrades.

== How To Test ==
This change should be mostly invisible to users. Check that during
upgrades services are restarted and that no warnings are emitted.

== User Experience ==
N/A

== Dependencies ==
N/A

== Contingency Plan ==

* Contingency mechanism: Revert to previous mechanism. This will
require a revert of changes to the spec file and a rebuild of the
package.

* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
TBD.

== Release Notes ==
Not needed.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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.fedoraproject.org


List of long term FTBFS packages to be retired in February

2020-01-02 Thread Miro Hrončok

Dear maintainers.

Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (February 
2020).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 30.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

Package  (co)maintainers   Latest build

elasticsearch hubbitus, jvanek, lbazan,Fedora 24
  zbyszek
expresso  jamielinux, nodejs-sig,  Fedora 28
  patches
libocrdma ocrdma   Fedora 27
nuvola-app-google-calendarmartinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media-martinkg Fedora 29
server
nuvola-app-plex   martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music   martinkg Fedora 29
shim-unsigned-aarch64 pjones   Fedora 28
shim-unsigned-x64 pjones   Fedora 28

The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2

Affected (co)maintainers
hubbitus: elasticsearch
jamielinux: expresso
jvanek: elasticsearch
lbazan: elasticsearch
martinkg: nuvola-app-soundcloud, nuvola-app-logitech-media-server, 
nuvola-app-yandex-music, nuvola-app-groove, nuvola-app-google-calendar, 
nuvola-app-plex

nodejs-sig: expresso
ocrdma: libocrdma
patches: expresso
pjones: shim-unsigned-aarch64, shim-unsigned-x64
tomh: expresso
zbyszek: elasticsearch


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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.fedoraproject.org


Orphaned packages looking for new maintainers

2020-01-02 Thread Miro Hrončok

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-12-31.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

MochiKit  orphan   2 weeks ago
apache-logging-parent mizdebsk, orphan 6 weeks ago
apachetop orphan, robert   2 weeks ago
audit-viewer  mitr, orphan 5 weeks ago
avalon-logkit jerboaa, mizdebsk, orphan5 weeks ago
binclock  lbalhar, orphan  2 weeks ago
buildnumber-maven-plugin  orphan   5 weeks ago
dzen2 bstinson, dcantrel, fale,4 weeks ago
  lupinix, orphan
exercism  go-sig, orphan   1 weeks ago
golang-github-codahale-   go-sig, orphan   1 weeks ago
aesnicheck
hystrix   orphan   5 weeks ago
i3-ipccicku, fale, gchamoul,   4 weeks ago
  lupinix, mpreisle, orphan
ike-scan  orphan, pwouters 2 weeks ago
infinispangil, orphan  5 weeks ago
jgraphx   jerboaa, orphan  1 weeks ago
libee mbartos, orphan  5 weeks ago
maven-ant-plugin  mizdebsk, orphan 3 weeks ago
maven-deploy-plugin   orphan   5 weeks ago
maven-docck-pluginmizdebsk, orphan 3 weeks ago
maven-ear-plugin  orphan   3 weeks ago
maven-war-plugin  mizdebsk, orphan 5 weeks ago
mcollective-qpid-plugin   orphan, tdawson  2 weeks ago
memoryfilesystem  orphan   5 weeks ago
multithreadedtc   orphan   3 weeks ago
nbtscan   orphan   2 weeks ago
nesc  cicku, orphan3 weeks ago
ninvaders orphan   2 weeks ago
ohc   acaringi, hhorak, orphan 5 weeks ago
oyranos   orphan   3 weeks ago
pscan orphan   2 weeks ago
python-dockerpty  lsm5, orphan, ttomecek   2 weeks ago
python-flask-classy   orphan   4 weeks ago
python-flask-debugtoolbar orphan   4 weeks ago
python-fsmonitor  orphan   4 weeks ago
python-mongoenginebowlofeggs, echevemaster,4 weeks ago
  orphan
python-nose-ignore-docstring  orphan   5 weeks ago
python-virtkeyorphan   2 weeks ago
qpid-proton   orphan   1 weeks ago
rubygem-awesome_spawn jstribny, orphan 3 weeks ago
rubygem-bootstrap-sassorphan   3 weeks ago
rubygem-charlock_holmes   orphan   3 weeks ago
rubygem-faker orphan   0 weeks ago
rubygem-omniauth  orphan   2 weeks ago
rubygem-orm_adapter   orphan   3 weeks ago
saxon dbhole, dchen, jjohnstn, 4 weeks ago
  mbooth, orphan
shed  orphan   2 weeks ago
sonatype-plugins-parent   mizdebsk, orphan 6 weeks ago
sound-theme-acoustic  orphan   0 

Orphaned packages looking for new maintainers

2020-01-02 Thread Miro Hrončok

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-12-23.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

ExchangeIRorphan   5 weeks ago
MochiKit  orphan   1 weeks ago
apache-logging-parent mizdebsk, orphan 5 weeks ago
apachetop orphan, robert   1 weeks ago
apt-cacher-ng orphan   5 weeks ago
archaius  orphan   5 weeks ago
archmage  lbazan, orphan   4 weeks ago
audit-viewer  mitr, orphan 4 weeks ago
avalon-logkit jerboaa, mizdebsk, orphan4 weeks ago
binclock  lbalhar, orphan  1 weeks ago
buildnumber-maven-plugin  orphan   4 weeks ago
camotics  orphan   5 weeks ago
cduce orphan   5 weeks ago
clapham   orphan   5 weeks ago
csstidy   orphan   5 weeks ago
delve go-sig, orphan   5 weeks ago
dzen2 bstinson, dcantrel, fale,3 weeks ago
  lupinix, orphan
eclipse-anyedit   eclipse-sig, orphan, swagiaal5 weeks ago
eclipse-checkstyleakurtakov, eclipse-sig, orphan   5 weeks ago
eclipse-color-theme   eclipse-sig, orphan  5 weeks ago
eclipse-dltk  akurtakov, eclipse-sig,  5 weeks ago
  kdaniel, orphan, rgrunber
eclipse-epic  eclipse-sig, orphan  5 weeks ago
eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan5 weeks ago
eclipse-m2e-cxf   eclipse-sig, mizdebsk, orphan5 weeks ago
eclipse-m2e-maven-dependency- mizdebsk, orphan 5 weeks ago
plugin
eclipse-m2e-modello   eclipse-sig, mizdebsk, orphan5 weeks ago
eclipse-m2e-plexuseclipse-sig, mizdebsk, orphan5 weeks ago
eclipse-m2e-sisu  eclipse-sig, mizdebsk, orphan5 weeks ago
eclipse-m2e-takarimizdebsk, orphan 5 weeks ago
eclipse-nls   orphan   5 weeks ago
eclipse-pdt   eclipse-sig, orphan  5 weeks ago
eclipse-quickrex  eclipse-sig, orphan  5 weeks ago
eclipse-sgx   orphan   5 weeks ago
exercism  go-sig, orphan   0 weeks ago
fabricorphan   5 weeks ago
ferm  orphan, slankes  5 weeks ago
giis  orphan   5 weeks ago
gipfelorphan   5 weeks ago
glob2 cheese, orphan   5 weeks ago
glusterd2 kkeithle, orphan 5 weeks ago
gns3-gui  orphan   5 weeks ago
gns3-net-converterorphan   5 weeks ago
gns3-server   orphan   5 weeks ago
golang-github-10gen-openssl   go-sig, jchaloup, mskalick,  5 weeks ago
  orphan
golang-github-codahale-   go-sig, orphan   0 weeks ago
aesnicheck
graphite-web  jamielinux, orphan, piotrp   5 weeks ago
guestfs-browser   orphan   5 weeks ago
hystrix   orphan   4 weeks ago
i3-ipc   

List of long term FTBFS packages to be retired in February

2020-01-02 Thread Miro Hrončok

Dear maintainers.

Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (February 
2020).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 30.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

Package  (co)maintainers   Latest build

elasticsearch hubbitus, jvanek, lbazan,Fedora 24
  zbyszek
expresso  jamielinux, nodejs-sig,  Fedora 28
  patches
libocrdma ocrdma   Fedora 27
nuvola-app-google-calendarmartinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media-martinkg Fedora 29
server
nuvola-app-plex   martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music   martinkg Fedora 29
shim-unsigned-aarch64 pjones   Fedora 28
shim-unsigned-x64 pjones   Fedora 28

The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2

Affected (co)maintainers
hubbitus: elasticsearch
jamielinux: expresso
jvanek: elasticsearch
lbazan: elasticsearch
martinkg: nuvola-app-logitech-media-server, nuvola-app-plex, nuvola-app-groove, 
nuvola-app-google-calendar, nuvola-app-soundcloud, nuvola-app-yandex-music

nodejs-sig: expresso
ocrdma: libocrdma
patches: expresso
pjones: shim-unsigned-aarch64, shim-unsigned-x64
tomh: expresso
zbyszek: elasticsearch


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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.fedoraproject.org