Will orphan packages with NEW F31FTBFS bugs tomorrow
by Miro Hrončok
According to the policy for packages that fail to build from source:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
I plan to orphan packages with NEW Fedora 31 Fail To Build From Source bugzillas
tomorrow.
By doing so, we notify the dependent package owners that something is wrong with
their dependency before it is removed.
Orphaned packages can be unorphaned without any damage.
When the packages stay orphaned for 6+ weeks, they will be retired.
Retired packages can be unretired. If they are retired for 8+ weeks, new package
review is needed.
Remember to set the bugzilla to ASSIGNED when you actually work towards fixing
the build failure.
The list would now be:
ferm
python-alchimia
vdirsyncer
python-sanic
ExchangeIR
aespipe
apt-cacher-ng
archaius
atanua
busybox
bval
camotics
cduce
clapham
couchdb
csstidy
delve
dumb-init
eclipse-anyedit
eclipse-avr
eclipse-checkstyle
eclipse-color-theme
eclipse-dltk
eclipse-egit
eclipse-emf
eclipse-epic
eclipse-gef
eclipse-license
eclipse-m2e-antlr
eclipse-m2e-apt
eclipse-m2e-buildhelper
eclipse-m2e-core
eclipse-m2e-cxf
eclipse-m2e-egit
eclipse-m2e-maven-dependency-plugin
eclipse-m2e-mavenarchiver
eclipse-m2e-mavendev
eclipse-m2e-modello
eclipse-m2e-plexus
eclipse-m2e-sisu
eclipse-m2e-takari
eclipse-m2e-tycho
eclipse-m2e-workspace
eclipse-m2e-wtp
eclipse-nls
eclipse-pdt
eclipse-photran
eclipse-ptp
eclipse-quickrex
eclipse-remote
eclipse-sgx
eclipse-subclipse
eclipse-testng
eclipse-usage
eclipse-webtools
efivar
erlang-clique
erlang-cluster_info
erlang-cuttlefish
erlang-erlando
erlang-erlydtl
erlang-riak_search
erlang-stdlib2
erlpmd
fop
giis
gipfel
glob2
glusterd2
golang-github-10gen-openssl
graphite-web
graphite2
gucharmap
guestfs-browser
ExchangeIR
apt-cacher-ng
archaius
atanua
ioprocess
isdn4k-utils
jdo-api
jogl2
jove
kf5-baloo
kf5-frameworkintegration
kf5-kactivities
kf5-kactivities-stats
kf5-kbookmarks
kf5-kcmutils
kf5-kconfigwidgets
kf5-kdeclarative
kf5-kded
kf5-kdelibs4support
kf5-kdesignerplugin
kf5-kdesu
kf5-kdewebkit
kf5-kemoticons
kf5-kglobalaccel
kf5-khtml
kf5-kinit
kf5-kio
kf5-kjs
kf5-kjsembed
kf5-kmediaplayer
kf5-knewstuff
kf5-knotifyconfig
kf5-kpackage
kf5-kparts
kf5-kpeople
kf5-kross
kf5-krunner
kf5-kservice
kf5-ktexteditor
kf5-ktextwidgets
kf5-kwallet
kf5-kxmlgui
kf5-kxmlrpcclient
kf5-purpose
kf5-syndication
kwalletmanager5
lbzip2
libcanberra
libgdiplus
libgovirt
libserf
libunity
libx86
lv2-abGate
lv2-kn0ck0ut
maven-checkstyle-plugin
maven-eclipse-plugin
merkaartor
mokutil
multibit-commons
multibit-hardware
nodejs-basic-auth
nodejs-buffertools
nodejs-bunyan
nodejs-chai-cheerio
nodejs-chai-fs
nodejs-commonmark
nodejs-compressible
nodejs-cors
nodejs-css-select
nodejs-csslint
nodejs-dateformat
nodejs-defence
nodejs-del
nodejs-delete
nodejs-encodeurl
nodejs-engine-dot-io-parser
nodejs-esprima
nodejs-eyes
nodejs-fake
nodejs-finalhandler
nodejs-find-cache-dir
nodejs-find-up
nodejs-flat-cache
nodejs-git-remote-origin-url
nodejs-globby
nodejs-gnode
nodejs-grunt-contrib-csslint
nodejs-grunt-legacy-util
nodejs-htmlparser2
nodejs-import-local
nodejs-jsonselect
nodejs-load-grunt-tasks
nodejs-make-dir
nodejs-method-override
nodejs-mock-bin
nodejs-mock-git
nodejs-moment
nodejs-negotiator
nodejs-only-shallow
nodejs-path-type
nodejs-pkg-dir
nodejs-pkg-up
nodejs-raw-body
nodejs-redent
nodejs-select-hose
nodejs-send
nodejs-stylus
nodejs-temp-write
nodejs-tilejson
nodejs-tilelive
nodejs-unique-stream
nodejs-vasync
nodejs-write
nodejs-xmlhttprequest
ocaml-bin-prot
ocaml-bisect
ocaml-bitstring
ocaml-camlp4
ocaml-deriving
ocaml-json-static
ocaml-mikmatch
ocaml-openin
ocaml-pa-monad
ocaml-pgocaml
ocaml-sexplib
ocaml-type-conv
ocamldsort
ohc
paulstretch
perdition
pesign
pesign-test-app
plasma-sdk
pyexiv2
python-bashate
python-cattrs
python-cloudservers
python-gfm
python-jira
python-k8sclient
python-pyopencl
python-subunit2sql
redeclipse
reg
resiprocate
rgbds
rubygem-cookiejar
rubygem-hiredis
sassc
scamper
scilab
sqlite2
swt-chart
tycho
tycho-extras
ugene
utop
zanshin
zathura-cb
zathura-djvu
zathura-pdf-mupdf
zathura-pdf-poppler
zathura-ps
zookeeper
This is coordinated (I'm talking to myself) in this releng ticket:
https://pagure.io/releng/issue/8917
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 6 months
Jenkins upgrade to change from fedmsg to fedora-messaging
by Jim Bair
Hello Fedora CI and Devel Teams!
The CI team will be performing a Jenkins upgrade and jms-messaging plugin
upgrade this Thursday to allow us to switch from fedmsg to
fedora-messaging. While performing this upgrade, dist-git tests will be
temporarily unavailable. When things are back to normal, we will reply-all
here.
Much like our last maintenance window, the intent is to upgrade the
software but not actually change from fedmsg to fedora-messaging just yet.
If you have any questions or concerns, by all means please reach out.
Thank you!
-Jim Bair
4 years, 6 months
Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
Enable module default streams in the buildroot repository for modular
and non-modular RPMs.
== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provided by module
default streams in the buildroot when building non-modular (or
"traditional") RPMs.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
* Responsible WG: Modularity WG
== Detailed Description ==
As a major part of the Modularity design, we have a concept of default
module streams. These streams are built as modules, but the RPM
artifacts they deliver are intended to be used just like non-modular
RPMS. The aspirational goal is that a user of the system who never
executes a module-specific command (such as `dnf module install
nodejs:8`) should experience no meaningful changes in behavior from
how they would interact with a completely non-modular system. In
practice, this may mean that the informational output of package
managers may indicate that modules are being enabled and used, but a
user that does not have a specific reason to interact with the
selection of a module stream should have that managed on their behalf.
Similarly, the experience for package maintainers of non-modular
packages should be unaffected by an RPM dependency moving from the
non-modular repository into a default module stream. Up to the
present, this has not been the case; no module stream content has been
available in the non-modular buildroot for other packages to consume.
Koji builds of non-modular RPMs have had only the other non-modular
RPMs from that release available to their buildroots. In contrast,
building on local systems has access to both the non-modular RPMs and
the RPMs from any of the default module streams. With this Change,
Koji builds will have the same behavior and be able to depend on
content provided by default module streams. It also enables the same
behavior for Modular builds: the `platform` stream will now include
the contents of the default module streams for each release and do not
need to be explicitly specified in the modulemd `buildrequires`.
Note: This Change does not address the other major Modularity issue we
are facing around distribution upgrades with differing default
streams. When discussing this Change, please keep that topic separate.
== Benefit to Fedora ==
This will simplify the lives of package maintainers in Fedora in two
primary ways. I'll use a hypothetical example of the Node.js
interpreter and a JSApp package which is capable of running on Node.js
10 or 12 (but requires newer features than are provided by Node.js 8).
Additionally, the JSApp package requires the same versions of Node.js
at build-time.
* Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F31 lifetime.
* Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F32 lifetime.
On Fedora 29 through 31, the Node.js package maintainer needs to build
the `nodejs:10` package both as a module and as a non-modular RPM in
the distribution so that the JSApp package can be built. With this
Change, the Node.js package maintainer in Fedora 32+ will only need to
build the various Node.js streams and make one of them the default
stream. The packages from it will then be added to the buildroot for
non-modular packages. This will also make the packaging process
somewhat more efficient, as the maintainer needs only to manage the
module stream and the MBS will build it for all configured platforms.
Similarly, from the perspective of dependent maintainers, there will
no longer be anxiety about needing to move their package to a module
if one or more of their dependencies drops their non-modular version
in favor of a default stream. Their builds will continue to work as
they do today.
== Scope ==
* Proposal owners:
# Update Packaging Guidelines with
[https://pagure.io/modularity/issue/146#comment-600328 requirements]
for module default streams
# Create a Pungi configuration to generate the buildroot from the
default module streams.
# Include `default_modules_scm_url` in the platform virtual module specification
# Configure Koji tags for inheriting the new modular-defaults
buildroot into the standard buildroot
* Other developers:
Packagers of default module streams will be required to conform to the
[https://pagure.io/modularity/issue/146#comment-600328 policy]
regarding visibility of stream artifacts. Any default module stream
that is not in compliance by one week before Beta Freeze will cease to
be a default stream.
* Release engineering:
# https://pagure.io/releng/issue/8879 - Create pungi config for
Rawhide/F32 ursa prime buildroot
# https://pagure.io/releng/issue/8880 - Include
`default_modules_scm_url` in platform 31 virtual module
# https://pagure.io/releng/issue/8881 - Configure Koji tags for
inheriting f32-modular-buildroot
* Policies and guidelines:
The Modularity Packaging Guidelines will need to be updated to
indicate the strict requirements on default streams.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change is on the build-system side of things and should not
impact the upgrade process directly.
== How To Test ==
# Build a modular stream
# Make that stream a default stream (or a buildroot override)
# Build a non-modular RPM that requires an artifact RPM from the modular stream.
== User Experience ==
This should not change the end-user experience.
== Dependencies ==
Nothing known that isn't listed in the scope.
== Contingency Plan ==
* Contingency mechanism: Disable the buildroot inheritance in Koji to
revert to the current behavior.
* Blocks release? Ambiguous: lack of complete implementation may
indirectly cause blocking issues.
* Blocks product? No
== Documentation ==
== Release Notes ==
None needed, the Change is not user-facing.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 6 months
Orphaning packages
by Othman Madjoudj
Hello,
Due to time constraints, I'm orphaning packages which I'm not using anymore.
rpms/fabric
rpms/gns3-gui
rpms/gns3-net-converter
rpms/gns3-server
rpms/python-aiohttp-cors
rpms/python-fluidity-sm
rpms/python-invoke
rpms/python-lexicon
rpms/python-multidict
rpms/python-spec
rpms/python-zipstream
Best regards.
-Othman
4 years, 6 months