devel-announce October 2019

devel-announce@lists.fedoraproject.org

7 participants
25 discussions

REMINDER: Fedora 31 Final Go/No-Go meeting Thursday
by Ben Cotton 23 Oct '19

23 Oct '19

This is your reminder that the Go/No-Go meeting for Fedora 31 is Thursday 24 October at 1400 UTC in #fedora-meeting Note that this is different than the usual time and channel. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

A new workflow for newcomers
by alciregi＠gmail.com 21 Oct '19

21 Oct '19

Hello, as you can read here [1], the Fedora Join SIG is experimenting a new people focused workflow for newcomers. In two words: people willing to contribute, instead of sending them directly to wiki pages or documentation sites, we would like to discuss with them and keep them in the wheel, while they discover the community, and look for a place where they are useful and happy to help. This is not an enforcing process, of course. People can still directly join (or ask to join) teams and follow SIG procedures as before. The new workflow is meant to help people who do not know enough about how Fedora works to take that step of joining a group and getting started with tasks. So, if you run into people that would like to contribute, but are undecided and in need of help with where/how they should get started, please address them to us[2]. Also, it'd be great if we can have more community members in these channels to answer questions and curiosities coming from potential new contributors. So please consider keeping an eye on them. [1] https://communityblog.fedoraproject.org/fedora-join-is-trying-a-new-people-… [2] https://fedoraproject.org/wiki/Welcome Thanks, A.

1 0

Orphaned packages looking for new maintainers
by Miro Hrončok 21 Oct '19

21 Oct '19

1 0

Updates to the FTBFS policy
by Miro Hrončok 20 Oct '19

20 Oct '19

Hello, after the recent discussions, the Fedora's "Fails to Build From Source" policy [0] has been updated [1][2]. The changes include: ## The policy no longer requires e-mails to devel to orphan a package This requirement made automation hard and resulted in most of the packages never being orphaned because almost nobody did this. The public e-mail about a certain package failing to build may have been seen as public shaming by some. ## Packages with NEW bugs will be orphaned after 8 weeks Orphaning packages where the maintainers don't respond at all makes sure that all the dependent package maintainers are properly notified about the problem long before the package is retired. ## Not orphaned packages are only retired after they FTBFS for 13+ months A week before Fedora N branching, packages that haven't built successfully at least on Fedora N-2 will be retired regardless of their FTBFS bug status. This allows the maintainers to postpone the package retirement, but not indefinitely. It also enforces that even if the bugs are closed by mistake, we don't miss any packages. The policy only allows the retirements to happen when there are several announcements about this on the devel list, with the list of packages. This makes sure nothing happens unexpectedly. I hope the changes will help assure Fedora packages stay in an generally healthy state without (especially occasional) Fedora contributors feeling intimidated by the rules. In any case, if you feel you need help when your package fails to build, please don't hesitate to use the devel mailing list to reach out, as does the document describing Fedora packager responsibilities [3] suggests. Thanks to everybody who was involved in this effort. [0] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails… [1] https://pagure.io/fesco/issue/2244 [2] https://pagure.io/fesco/fesco-docs/pull-request/18 [3] https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilit… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Fedora 32 System-Wide Change proposal: On-demand Side Tags
by Ben Cotton 18 Oct '19

18 Oct '19

https://fedoraproject.org/wiki/Changes/OnDemandSideTags see also: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… = On-demand Side Tags = == Summary == Allow on-demand side tags, and allow packagers to a) tag whatever rpms as build dependencies into those side tags, b) build packages they want in those side tags, and then c) tag all or some of those new packages back into appropriate “main” tag (e.g. fNN-updates-candidate). This new process will allow packagers to build rpms using older or newer versions of build dependencies than the buildroot in a given Fedora release, providing a subset of Modularity features in an additive way (no influence on the way dependent packages are built or installed). It may also coexist with Modularity in its current form. As a policy change, default modules are disallowed and modules are only opt-in. == Owners == * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in.waw.pl * Name: [[User:Churchyard| Miro Hrončok]] * Email: == Detailed Description == === Motivation === Modularity in its design and current implementation provides a number of features that can be divided into two: for people ''building rpms in modules'', and for people ''installing rpms from modules''. There have been a number of issues, RFEs, and discussions about modularity, but they are mostly about the second, user-facing part. Rpms installed from modules interact with non-modular rpms, and of course every aspect of this interaction is visible to users. To make Modularity a success, we would not only need to make this interaction well-behaved, we would also need to explain it to users in a satisfactory way. The first part, module build internals, is not visible to users. Some packagers don’t like the syntax, which is opaque and best-suited for programmatic generation and consumption. Constant rebuilding of modules also creates noticeable load on the infrastructure, making everything else slower. If modularity became much more popular, and a significant number of packagers was using it, we are convinced many discussions would start about this first part too. Despite some problems, there is clear demand for the features that Modularity brings. In particular, we need some solution for the "too fast too slow" problem, where some packages cannot update fast enough to maintain compatibility with the rest of the distribution. === New approach: on-demand side tags === The new process proposed here provides an alternative to both parts of Modularity. The second part of Modularity is simply removed: '''users only get normal rpms'''. After rpms have been built, some or all of them are merged into the normal tags and delivered to users as usual. This is pretty much the same as the usual rebuild of specific language or graphic stacks in side tags that we do already. Dependencies between rpms must be expressed using Requires/Recommends/Provides/Suggests/Conflicts. The first part is replaced by a simpler scheme: '''we don’t define any specific syntax or repositories to build packages'''. The packager has to issue a sequence of 'fedpkg tag-build', 'fedpkg build', and 'koji wait-repo' commands as appropriate (or 'fedpkg chain-build' or …). The packager ''may'' link an older rpm into the side tag, allowing building against old versions of packages. This means that if the packager is not a committer to the package, they may only use a version which was previously built in koji. The packager selects which rpms should be merged back into the main tag. Old packages obviously cannot be merged back. To minimize disruption for users and current packagers, modules are required to be opt-in only. There are no default modules and non-modular rpms cannot depend for build or installation on modular rpms. This way there is less burden to other packagers and Modularity can evolve more easily. === Implementation === '''Ability to create side tags “on demand”, i.e. with an automated API call''' must be implemented. Koji and other infra tools would need to be able to deal with a large number of tags. Modularity already creates a large number of tags, so this should not be a significant change. Packager tools like fedpkg must grow '''new commands to create side tags'''. Both the workflow in this proposal, and modules as they currently are would be allowed to coexist. After we have some experience with both approaches, one or both could be retired. Since this proposal removes the possibility to have default modules, '''modules need to be reset'''. The details are not specified yet. One approach would be to do the equivalent of dnf module reset all during upgrade to F32, similarly to the proposed solution for https://bugzilla.redhat.com/show_bug.cgi?id=1747408. This proposal assumes that '''fedpkg will be enhanced to do extended chain builds smartly'''. This is not a precondition: even without that packagers may script something that is appropriate for them. This is one of the main advantages of the proposal: we put the “smarts” in local tooling which can be enhanced and modified without breaking what other packagers do. E.g. a solution to rebuild all 500 rust packages with new versions may be significantly different than building a compat version of postgresql, and that is OK. === Buildroot only packages === They are possible, because not all packages are merged back. The same is currently possible with side tags, and with non-rawhide builds for which packagers may never create a bodhi update, so there is no fundamental change. Whether or not we need to disallow packages which are purposefully buildroot-only by a policy is left out of this proposal on purpose. Technically, it is possible. == Benefit to Fedora == === Costs, for packages converted from modules to this scheme === Transitional costs: according to this proposal, modules may still be used. Nevertheless, if the contents of a module are to be used to build normal rpms, that module will need to switch to the new process or simply demodularized and built in the traditional way. In the case where this happens, packaging would need to be “translated” from module .yaml to normal spec files. This should mostly be about adjusting metadata, i.e. package versions and dependencies. We would lose one of the main advertised features of Modularity: the ability to build the same module in different versions. This might not be a huge loss, for two reasons. First, great majority of modules are single-version. Second, if desired it is possible to provide compat packages with different names. This is a bit of annoying work, but we have the process very well understood. Compat packages have the additional advantage that they may be made co-installable (vide python26, python2, python35, python36, python3, python38 packages currently in F31). Compat packages are exempt from package review. We may consider additional simplifications to the process to make compat packages easier. === Benefits === Vast simplification for other packagers, i.e. those who would like to depend on rpms which are currently modularized, and for users, who do not have separate modular repos, just a single repo like before. Reduced load on the build infrastructure. Easier to find rpm sources because there again is one canonical repo. Third parties building on top of Fedora can use our modules to build their own rpms without trouble. dnf does not need to handle complicated logic. It should be faster if less repos are used. Rpms are built against an up-to-date buildroot, with only the minimal compat package inserted, instead of some older-than-all-current-releases Fedora release. Normal package-level package replacement and obsoletion mechanisms are used. On-demand side tags will remove the need to open releng tickets to have them manually created. == Scope == * Proposal owners: detailed documentation how to do things in the new scheme, client-side tooling improvements. * Other developers: demodularize specific packages if wanted or necessary. * Release engineering: implement the server side of side tags on demand [RELENG TICKET WILL BE FILED LATER] * Policies and guidelines: the docs would need to be added to packager documentation. Pull requests will be submitted by proposal owners. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This change should be fully additive to normal rpm packaging, so there should be no upgrade/compatibility issues. Some modules will need to be demodularized. This will require packager work. Once this happens, rpms built this way will be fully available to build normal rpms and modules, so the upgrade impact should be limited to the modules being rewritten. == How To Test a.k.a. examples of the new workflow == === Version bump in a language stack === It is determined that a new set of rust rpm versions should be built. A member of the rust-sig bumps the versions in dist-git for all relevant packages, creates a side tag, and does the huge chain-build. Once finished, this side tag is merged into rawhide-build. If desired, it may also be merged into f31-updates-candidate and/or f30-updates-candidate and bodhi updates submitted. rust-sig already has tooling to generate the appropriate build-order for modularity’s .yaml file. The same code can be reused to generate the order for the chain build. === Three streams of a database package === A security patch needs to be applied to three versions of postgresql. There are postgresql, postgresql82, postgresql81 dist-git repos. The patch is added in dist-git for each of the packages, and they are rebuilt as appropriate. Since we want to build each package with different compiler versions, the packager uses a bash loop to schedule separate builds of each of the three packages in each of the supported Fedora versions. (Once we have automatic creation of bodhi updates from koji builds, the packager will not have to do anything more. Right now they still need to create one big update that will then be split into separate updates for each Fedora release.) A small advantage compared to current modules is that packages are not built against an already obsolete Fedora base, so users get the benefit of toolchain improvements. === Package needs some old dep to build === Poor packager needs gcc-9.0, at the time where gcc-9.1 is the default in the build root, to build koo. They bump the version of koo in dist-git, create a side tag, tag old gcc-9.0-12.fc31 build into the tag, build koo, merge the built package back into f32-build and f31-updates-candidate. === Package needs some old dep to install === koo-gui is only compatible with python3-qt5-5.12 when python3-qt5-5.13 has been released, and cannot be built with the new version. koo maintainers may either a) arrange for python-qt5_5_12 compat package to be created and then use it in the build root and as installation dep, b) install old python3-qt5-5.12 package in build root, and bundle some contents of that package into its output rpms, and add Provides:bundled(python3-qt5)=5.12. === FAQ for “other developers” === ==== I maintain several modular streams of my package additionally to the default version in Fedora. Can I keep doing this? ==== Yes, you can keep any alternate version in modular branches. When appropriate, consider compat packages that can often be co-installable, unlike modular streams. ==== I maintain my packages as modular only. Can I keep doing this? ==== Yes, as long as those modules are “leaves”, in the sense that no non-modular rpms depend on them. ==== I would like to use an rpm which is currently only available as module as a build dependency ==== The owner of the module should be asked to demodularize the module (and either convert it to fully traditional rpms, or build some rpms using the new side-tag process). Those rpms can then be used as build- and installation-time dependencies. If the owner of the module is not interested in providing non-modular rpms, other packages may add such rpms to the distribution (and again build them in one of the two ways). ==== Which rpms can be used as build dependencies in the side tag? ==== In principle, any rpm which is available in koji (including the recursive dependencies, so it can actually be installed). In addition, the packager may build rpms and use them in the side tag build root. In practice, we expect that packagers will use one of the Fedora releases (with updates), as the base. == User Experience == Users have a clearer picture where their rpms are coming from. If they opt-in into a module, they get some additional content. Without that, they only get rpms from the normal Fedora repository. They are able to rebuild rpms locally if there are no version conflicts. In case of version conflicts, they might need to install older versions of rpms from koji to satisfy the build (which might sound bad, but really isn’t much different from current state with normal rpms.) == Dependencies == On-demand side tags. Without this, this would be completely infeasible. For limited and initial testing, side tags could be created manually. == Contingency Plan == In the implementation phase, this should not impact other rpms in any way (since it is change really happens on the build farm). Once deployed, and rpms are built using this approach, they would still be installable, even if the new process is abandonded. So there is no flag day for revert, but some packages would effectively become FTBFS. Any rpms which can only be built in this new scheme (e.g. because they require older packages that the current ones in the default build root), would have to be either fixed to build in the normal build root, or would have to be modularized. If this approach is abandoned, other approaches including the proposal in https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot may be implemented, but that is only possible in the longer term. * Contingency mechanism: 1. disable side-tag creation in koji (releng). Hopefully this would be just a single switch somewhere. Any code that is added to koji can be removed later (koji developers). 2. undo any documentation changes 3. adjust packages as described above (change owners, package owners). This is very hard to say how big the scope of this would be, because it is unclear how many packages would be involed. I think we can assume that similarly as with Modularity, it would be <10 in the first Fedora release where this is available. * Contingency deadline: TBD * Blocks release? Yes == Documentation == Will be submitted by Change owners. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 31 Final is No-Go
by Ben Cotton 17 Oct '19

17 Oct '19

Release status of Fedora 31 Final is NO-GO. Due to open blocker bugs and the lack of a release candidate, Fedora 31 Final was declared "No-Go". We will reconvene at 1400 UTC (note the departure from the usual time) on Thursday, 24 October[1] to target a release date of Tuesday 29 October. For more information, please see the minutes[2] from the Fedora 31 Final Go/No-Go meeting. [1] https://apps.fedoraproject.org/calendar/Fedora%20release/2019/10/24/#m9641 [2] https://meetbot.fedoraproject.org/teams/f31-final-go_no_go-meeting/f31-fina… -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Orphaned packages looking for new maintainers
by Miro Hrončok 14 Oct '19

14 Oct '19

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 releng issues: https://pagure.io/releng/issues Full report available at: https://churchyard.fedorapeople.org/orphans-2019-10-14.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change ================================================================================ PyRTF orphan 5 weeks ago RackTables orphan 5 weeks ago TeXamator orphan 5 weeks ago XmlSchema msimacek, orphan 5 weeks ago alacarte alexl, caillon, caolanm, 4 weeks ago johnp, mbarnes, orphan, rhughes, ssp anyremote orphan 5 weeks ago apache-commons-launcher orphan 5 weeks ago audio-convert-mod orphan 4 weeks ago batti orphan 4 weeks ago bios_extract orphan 5 weeks ago bzr orphan 2 weeks ago captcp orphan 5 weeks ago cassandra acaringi, hhorak, jjanco, 3 weeks ago orphan, rimolive castor-maven-plugin orphan 2 weeks ago cbi-plugins eclipse-sig, kdaniel, orphan, 3 weeks ago rgrunber certmaster alikins, orphan, robert, 5 weeks ago wakko666 check-mk orphan 5 weeks ago chm2pdf orphan 4 weeks ago comedilib orphan 5 weeks ago concurrentunit orphan 5 weeks ago diffuse cicku, fab, orphan 1 weeks ago drobo-utils imntreal, orphan 5 weeks ago eclipse-dtp eclipse-sig, galileo, kdaniel, 3 weeks ago mbooth, orphan eclipse-ecf eclipse-sig, kdaniel, orphan, 3 weeks ago rgrunber eclipse-eclemma eclipse-sig, jerboaa, kdaniel, 3 weeks ago orphan, rgrunber eclipse-egit-github eclipse-sig, orphan 3 weeks ago eclipse-linuxtools eclipse-sig, jjohnstn, orphan, 3 weeks ago rgrunber eclipse-moreunit jerboaa, orphan 3 weeks ago eclipse-mpc eclipse-sig, kdaniel, orphan, 3 weeks ago rgrunber eclipse-mylyn arobinso, eclipse-sig, 3 weeks ago jjohnstn, kdaniel, orphan, rgrunber eclipse-packagekit eclipse-sig, jerboaa, kdaniel, 3 weeks ago orphan, rgrunber eclipse-pydev eclipse-sig, jjohnstn, orphan 3 weeks ago eclipse-swtbot eclipse-sig, orphan 3 weeks ago eclipse-tm-terminal eclipse-sig, orphan 3 weeks ago epydoc orphan, thias 5 weeks ago euca2ools orphan 4 weeks ago felix-main orphan 5 weeks ago fishpoll marionline, orphan 5 weeks ago freemedforms nobrakal, orphan 3 weeks ago freenx-server orphan 5 weeks ago func alikins, orphan, robert, 4 weeks ago wakko666 fuse-python moezroy, orphan 5 weeks ago gadget orphan 5 weeks ago gcc-python-plugin jakub, orphan 4 weeks ago ginfo orphan, stevetraylen 4 weeks ago git-bz orphan 5 weeks ago git-remote-bzr orphan 3 weeks ago gnome-python2-extras alexl, caillon, caolanm, 4 weeks ago gnome-sig, johnp, mikedep333, orphan, rhughes, rstrode, ssp gnu-regexp dbhole, mizdebsk, orphan 2 weeks ago gstreamer-python company, orphan, tomspur 4 weeks ago gtkparasite ivazquez, orphan 5 weeks ago ivykis jpo, orphan 0 weeks ago jarjar mizdebsk, orphan 5 weeks ago java-base64 orphan 3 weeks ago java-uuid-generator orphan 5 weeks ago jboss-jstl-1.2-api mmraka, orphan 3 weeks ago jetty-version-maven-plugin mizdebsk, orphan 3 weeks ago js-excanvas nodejs-sig, orphan, rathann, 2 weeks ago williamjmorenor json_diff orphan 1 weeks ago jthread orphan 5 weeks ago kig jreznik, kde-sig, orphan, 5 weeks ago rdieter kross-interpreters jreznik, kde-sig, orphan, 5 weeks ago rdieter laditools orphan 4 weeks ago leafnode orphan 1 weeks ago libdasm orphan 5 weeks ago libfixposix orphan 2 weeks ago libodb-boost daveisfera, orphan 0 weeks ago libodb-qt daveisfera, orphan 0 weeks ago libopensync orphan 5 weeks ago mach orphan 5 weeks ago marave orphan 5 weeks ago menulibre orphan 0 weeks ago mirrorbrain orphan 5 weeks ago mkelfimage orphan 3 weeks ago moin ivazquez, mmcgrath, orphan 5 weeks ago nfft lupinix, orphan 5 weeks ago nfspy orphan 0 weeks ago nodejs-flot nodejs-sig, orphan, rathann, 2 weeks ago vjancik, williamjmorenor notify-python orphan 2 weeks ago openstv orphan 5 weeks ago openxcap orphan 4 weeks ago patcher orphan, tomspur 5 weeks ago pdf-renderer orphan 4 weeks ago pegdown mizdebsk, orphan 2 weeks ago pilas martinlanghoff, orphan 5 weeks ago pipestat orphan 5 weeks ago pius amitshah, fale, orphan 5 weeks ago powerpc-utils-python orphan 5 weeks ago pycdio orphan 5 weeks ago pycscope orphan 5 weeks ago pyftpdlib orphan 4 weeks ago pypoppler orphan 0 weeks ago python-Lektor orphan 5 weeks ago python-application orphan, salimma 5 weeks ago python-arc orphan 0 weeks ago python-backports- ianweller, infra-sig, orphan, 4 weeks ago ssl_match_hostname ralph python-cassandra-driver filabrazilska, lkundrak, 3 weeks ago orphan, praiskup python-chm lbazan, narasim, orphan, 4 weeks ago pertusus python-epdb arg, orphan, pjones 4 weeks ago python-gnutls gnat, orphan 5 weeks ago python-inifile orphan, python-sig 5 weeks ago python-ipaddress orphan, pwouters 6 weeks ago python-jenkinsapi cottsay, orphan 4 weeks ago python-kiwi-gtk orphan 5 weeks ago python-ngram orphan 4 weeks ago python-openid orphan 4 weeks ago python-pp orphan 5 weeks ago python-progressbar cdamian, orphan, pviktori 4 weeks ago python-pybloomfiltermmap orphan 4 weeks ago python-pysmell orphan, patches 5 weeks ago python-qpid orphan 4 weeks ago python-requestbuilder orphan 5 weeks ago python-sexy orphan 5 weeks ago python-sippy orphan 5 weeks ago python-sparklines orphan, ralph 5 weeks ago python-speedtest-cli orphan 4 weeks ago python-tbgrep infra-sig, orphan, ralph 4 weeks ago python-tpg orphan 4 weeks ago python-unittest2 aviso, bkabrda, carlwgeorge, 1 weeks ago churchyard, mbacovsk, orphan, pjp, python-sig, sundaram, ttorling python2-typing chandankumar, orphan 4 weeks ago q-text-as-data orphan 5 weeks ago qpid-cpp nsantos, orphan 4 weeks ago qtermwidget-qt4 lupinix, lxqt-sig, orphan, 5 weeks ago tieugene qtools orphan 5 weeks ago radiotray orphan 4 weeks ago rawdog orphan 5 weeks ago rootfs-resize orphan, robert 5 weeks ago sidc-gui orphan 5 weeks ago sl orphan 1 weeks ago slrn orphan 1 weeks ago soscleaner orphan 5 weeks ago sparcy orphan 5 weeks ago sqlcli orphan 5 weeks ago stringtemplate4 mizdebsk, mjakubicek, orphan 3 weeks ago subdownloader orphan 4 weeks ago syslog-ng czanik, jpo, mrunge, orphan 0 weeks ago system-config-httpd orphan, pknirsch 1 weeks ago system-config-keyboard itamarjp, nphilipp, orphan, 5 weeks ago raveit65, twoerner system-switch-displaymanager orphan 5 weeks ago tagsoup mizdebsk, orphan 3 weeks ago tellico alexlan, orphan 5 weeks ago thunderbird-enigmail orphan 5 weeks ago umit fab, orphan 5 weeks ago virtio-forwarder orphan 0 weeks ago wammu orphan 3 weeks ago winswitch orphan 4 weeks ago wraplinux orphan 3 weeks ago wtop orphan 5 weeks ago xhotkeys orphan 5 weeks ago xxdiff orphan 5 weeks ago yaws orphan 0 weeks ago zynjacku orphan 4 weeks ago The following packages require above mentioned packages: See https://churchyard.fedorapeople.org/orphans-2019-10-14.txt Grep it for your username and follow the dependency chain. Affected (co)maintainers abompard: python-unittest2, python-ipaddress, python-backports-ssl_match_hostname acaringi: cassandra, jarjar, felix-main, python-cassandra-driver adamwill: python-unittest2 akurtakov: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal alexl: alacarte, gnome-python2-extras alexlan: tellico alikins: certmaster, func amerey: jarjar amitshah: pius, jarjar ankursinha: js-excanvas, nodejs-flot, bzr anyremote: anyremote apevec: python-unittest2 arg: python-epdb arobinso: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal, castor-maven-plugin athoscr: python-unittest2 aviso: python2-typing, python-unittest2 awjb: libopensync awood: felix-main ayrx: python-ipaddress berrange: jarjar bkabrda: python-unittest2, bzr bonzini: jarjar bowlofeggs: python-ipaddress bressers: comedilib brouhaha: comedilib caillon: alacarte, gnome-python2-extras caolanm: alacarte, gnome-python2-extras carlwgeorge: python-unittest2 cdamian: python-progressbar chandankumar: python2-typing cheese: libopensync cheimes: python-ipaddress churchyard: python-unittest2, bzr cicku: diffuse clime: euca2ools, python-progressbar, python-requestbuilder, epydoc company: gstreamer-python cottsay: comedilib, python-jenkinsapi, bzr cqi: python-unittest2 cquad: jboss-jstl-1.2-api crobinso: jarjar ctubbsii: js-excanvas, jarjar, nodejs-flot czanik: ivykis, syslog-ng daveisfera: libodb-qt, libodb-boost daveo: comedilib davidcl: tagsoup dbhole: cbi-plugins, eclipse-swtbot, gnu-regexp, eclipse-linuxtools, eclipse-mylyn, tagsoup, eclipse-ecf, eclipse-tm-terminal, jarjar dcallagh: python-unittest2 dchen: jarjar, tagsoup, stringtemplate4 dgoodwin: felix-main dmach: python-unittest2 drsmith2: jarjar dturecek: euca2ools, python-progressbar, python-requestbuilder, epydoc dustymabe: python-unittest2 dwmw2: jarjar ebaron: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal eclipse-sig: eclipse-egit-github, cbi-plugins, eclipse-mpc, eclipse-swtbot, gnu-regexp, eclipse-dtp, eclipse-linuxtools, eclipse-mylyn, eclipse-packagekit, eclipse-ecf, eclipse-tm-terminal, eclipse-pydev, jarjar, eclipse-eclemma, jetty-version-maven-plugin eclipseo: python-unittest2, bzr ehabkost: jarjar elwell: python-unittest2 fab: fuse-python, pypoppler, python-unittest2, umit, diffuse fale: pius, python-unittest2 fche: jarjar filabrazilska: python-cassandra-driver frostyx: euca2ools, python-progressbar, python-requestbuilder, epydoc galileo: eclipse-dtp gholms: python-unittest2 gil: stringtemplate4 gnat: python-gnutls gnome-sig: gnome-python2-extras go-sig: bzr greghellings: python-unittest2 grenier: fuse-python grover: epydoc herlo: python-unittest2 hguemar: python-unittest2 hhorak: cassandra, jarjar, felix-main, python-cassandra-driver hubbitus: java-base64 ianweller: python-backports-ssl_match_hostname ignatenkobrain: python-unittest2, epydoc imcleod: euca2ools, python-progressbar, python-requestbuilder imntreal: drobo-utils infra-sig: python-tbgrep, python-ipaddress, python-backports-ssl_match_hostname irina: qpid-cpp, epydoc, python-qpid itamarjp: python-ipaddress, system-config-keyboard ivazquez: gtkparasite, moin jakub: gcc-python-plugin jamielinux: jarjar, bzr java-sig: felix-main jcline: python-unittest2, python-ipaddress, python-backports-ssl_match_hostname jerboaa: cbi-plugins, eclipse-moreunit, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-packagekit, eclipse-ecf, eclipse-tm-terminal, jarjar, eclipse-eclemma jforbes: jarjar jgu: java-base64 jistone: jarjar jjames: stringtemplate4, epydoc jjanco: cassandra, jarjar, felix-main, python-cassandra-driver jjelen: jboss-jstl-1.2-api jjohnstn: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, tagsoup, eclipse-ecf, eclipse-tm-terminal, eclipse-pydev, jarjar jkastner: stringtemplate4 johnp: alacarte, gnome-python2-extras jonny: felix-main, java-base64 jpena: python-unittest2 jpo: ivykis, syslog-ng jraber: gnome-python2-extras, PyRTF, pypoppler jreznik: kig, kross-interpreters jskarvad: comedilib, jarjar jspaleta: gnome-python2-extras, PyRTF, pypoppler juergh: euca2ools, python-progressbar, python-requestbuilder jujens: python-unittest2 jussilehtola: tagsoup jvanek: jarjar, tagsoup, java-base64 kdaniel: cbi-plugins, eclipse-mpc, eclipse-swtbot, eclipse-dtp, eclipse-linuxtools, eclipse-mylyn, eclipse-packagekit, eclipse-ecf, eclipse-tm-terminal, eclipse-eclemma kde-sig: kig, kross-interpreters kevin: python-openid, bzr kumarpraveen: python-unittest2 kwizart: fuse-python larsks: python-unittest2 lbazan: python-unittest2, python-chm, java-base64 lberk: jarjar lef: cbi-plugins, jboss-jstl-1.2-api, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal, castor-maven-plugin, stringtemplate4, jarjar limb: bzr lkundrak: jarjar, python-cassandra-driver lmacken: python-unittest2 louizatakk: python2-typing lsedlar: python-unittest2 lupinix: nfft, qtermwidget-qt4 luya: epydoc lxqt-sig: qtermwidget-qt4 marionline: fishpoll martinlanghoff: pilas mathstuf: bzr maxamillion: python-unittest2 mbacovsk: python-unittest2 mbarnes: alacarte mbooth: cbi-plugins, eclipse-swtbot, gnu-regexp, eclipse-linuxtools, eclipse-dtp, eclipse-mylyn, tagsoup, eclipse-ecf, eclipse-tm-terminal, jarjar mcrha: libopensync mdbooth: fuse-python melmorabity: notify-python, python-sexy mhayden: python-unittest2 mikedep333: gnome-python2-extras milleruntime: js-excanvas, jarjar, nodejs-flot mitr: python2-typing, python-sexy mizdebsk: js-excanvas, eclipse-swtbot, gnu-regexp, pegdown, eclipse-linuxtools, eclipse-mylyn, java-base64, tagsoup, eclipse-ecf, eclipse-tm-terminal, felix-main, stringtemplate4, jarjar, nodejs-flot, jetty-version-maven-plugin mjakubicek: stringtemplate4 mjw: jarjar mkrizek: fuse-python mlombard: epydoc mmahut: comedilib, python-unittest2 mmcgrath: moin mmraka: jboss-jstl-1.2-api moezroy: fuse-python mrunge: ivykis, python-unittest2, syslog-ng mruszczyk: pycdio mschorm: felix-main msimacek: XmlSchema msuchy: euca2ools, python-progressbar, python-requestbuilder, epydoc narasim: python-chm ncoghlan: bzr neuro-sig: js-excanvas, python-unittest2, nodejs-flot ngompa: js-excanvas, python2-typing, python-unittest2, jarjar, nodejs-flot nguzman: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal nobrakal: freemedforms nodejs-sig: js-excanvas, jarjar, nodejs-flot noodles: python-ipaddress nphilipp: system-config-keyboard npmccallum: python-ipaddress nsantos: qpid-cpp, epydoc, python-qpid odubaj: jarjar, felix-main oliver: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal olysonek: jarjar omajid: tagsoup ondrejj: python-unittest2 onosek: python-unittest2 orion: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, tagsoup, eclipse-ecf, eclipse-tm-terminal, felix-main patches: python-pysmell, jarjar pcpa: tagsoup pertusus: python-chm petersen: bzr pgordon: gnome-python2-extras, PyRTF, pypoppler pingou: python-unittest2 pjones: python-epdb pjp: python-unittest2 pknirsch: system-config-httpd, jarjar pmackinn: jetty-version-maven-plugin pmikova: jarjar praiskup: epydoc, python-cassandra-driver, python-requestbuilder, euca2ools, python-progressbar pspacek: python2-typing ptoscano: fuse-python puiterwijk: python-openid pviktori: python-progressbar pwouters: python2-typing, python-ipaddress python-sig: js-excanvas, python2-typing, python-inifile, pyftpdlib, python-unittest2, jarjar, nodejs-flot, bzr qa-tools-sig: fuse-python quintela: jarjar qulogic: js-excanvas, pyftpdlib, jarjar, nodejs-flot, bzr radekmanak: jarjar ralph: python-ipaddress, python-backports-ssl_match_hostname, python-sparklines, python-tbgrep, python-unittest2 raphgro: python-unittest2 rathann: js-excanvas, jarjar, nodejs-flot raveit65: system-config-keyboard rdieter: kig, kross-interpreters rebus: fuse-python rfenkhuber: felix-main rgrunber: cbi-plugins, eclipse-mpc, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-packagekit, eclipse-ecf, eclipse-tm-terminal, jarjar, eclipse-eclemma rhughes: alacarte, gnome-python2-extras rimolive: cassandra, jarjar, felix-main, python-cassandra-driver rjones: jarjar, fuse-python rmarko: python-unittest2 rmattes: bzr rmyers: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal robert: certmaster, bzr, func, rootfs-resize robotics-sig: bzr rstrode: gnome-python2-extras sagarun: python-ipaddress, python-backports-ssl_match_hostname sagitter: python-unittest2 salimma: python-unittest2, python-application scox: jarjar sdgathman: stringtemplate4 sharkcz: comedilib slaanesh: epydoc smakarov: jarjar sopotc: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal ssp: alacarte, gnome-python2-extras stevetraylen: ginfo sundaram: python-unittest2, bzr tdawson: python-unittest2 tflink: fuse-python thias: epydoc thm: bzr tieugene: qtermwidget-qt4 tjikkun: python-unittest2 tomspur: patcher, gstreamer-python torsava: bzr trepik: felix-main ttorling: python-unittest2, bzr twoerner: system-config-keyboard virtmaint-sig: jarjar vjancik: js-excanvas, jarjar, nodejs-flot vladimirk: cbi-plugins, eclipse-swtbot, eclipse-linuxtools, eclipse-mylyn, eclipse-ecf, eclipse-tm-terminal wakko666: certmaster, func walters: stringtemplate4 wcohen: jarjar weli: jarjar, tagsoup williamjmorenor: js-excanvas, jarjar, nodejs-flot wwoods: python-unittest2 yograterol: python-unittest2 zbyszek: jarjar, java-base64 -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0
by Ben Cotton 10 Oct '19

10 Oct '19

https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0 == Summary == Update the Free Pascal Compiler used within Fedora to version 3.2.0, once it is published, and enable building (previously unsupported) AArch64 and ppc64le packages using the compiler. == Owners == * Name: [[User:suve|Artur Iwicki]] * Email: <fedora(a)svgames.pl> * Name: [[User:joost|Joost van der Sluis]] * Email: <joost(a)cnoc.nl> == Detailed Description == The Free Pascal Compiler team plans to release a new release, 3.2.0, somewhere until the end of this year (2019). This date falls within the Fedora 32 release schedule, so the new compiler version could be introduced into F32 once it's released. == Benefit to Fedora == The Free Pascal Compiler will support new architectures, which in turn will allow programs compiled using FPC to run on more architectures supported by Fedora. See also [https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New Features 3.2] for a list of other new compiler features. == Scope == All packages depending on `fpc` should be rebuilt with the new `fpc` once it hits F32, or, if there is not enough time for that, just all packages built after the new `fpc` hits the buildroots. * Proposal owners: ** Update the `fpc` package to version 3.2.0. ** Cross-compile the compiler for AArch64 and ppc64le (required for bootstrapping). ** Add AArch64 and ppc64le to the `ExclusiveArch:` tag in the package spec. ** Build the compiler for the new architectures, using the cross-compiled binaries. ** Build the compiler once again, this time using the self-hosted binary. ** Update the `fpc-rpm-macros` package to accurately reflect the new, expanded architecture list. * Other developers: In the first few days or weeks, just voluntary rebuilds using the new `fpc`. Should there be any build failures, look at the [https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2] page to see if the package is affected by any backwards-incompatible change. If the packaged program/library does not support one of the newly introduced architectures (AArch64/ppc64le), either resolve the issue or add an `ExcludeArch:` tag to the spec. * Release engineering: Mass rebuild requested for F32. * Policies and guidelines: No changes needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact == How To Test == Since the main impact of this change is adding support for new architectures, a mass-rebuild of dependent packages will also act as a test. Users wanting to test this change may want to submit a scratch build against rawhide. If needed, a [b]copr[/b] repo may also be created, so anyone interested may install the compiler on F31 or F30. == User Experience == FPC-dependent packages will become available on a larger number of architectures. == Dependencies == Lazarus depends on FPC exact version, so it will 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. I do not expect the compiler to introduce any bugs for x86 / x86_64 / ARM, so the main question will be whether the new AArch64 and ppc64le targets work correctly. * Contingency mechanism: If errors occur only for AArch64 / ppc64le builds, keep the compiler at the new version (3.2.0), but disable AArch64 and ppc64le (attempt to enable them again once F32 branches from Rawhide). If errors are also spotted on x86 / x86_64 / ARM, revert to the the older version (3.0.4). After choosing either option, perform a mass rebuild of dependent packages. * Contingency deadline: Before release * Blocks release? No * Blocks product? No == Documentation == Free Pascal wiki pages: * [https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New Features 3.2] * [https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2] == Release Notes == Fedora 32 ships with Free Pascal Compiler 3.2.0, see the [https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New Features 3.2] page for a list of new features and consult the [https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2] page for a list of backwards-incompatible changes. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
by Ben Cotton 09 Oct '19

09 Oct '19

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

1 0

Fedora 31 Final Go/No-Go meeting
by Ben Cotton 09 Oct '19

09 Oct '19

Dear all, The Go/No-Go meeting for the Fedora 31 Beta release will be held on Thursday, 2019-10-17 at 17:00 UTC in #fedora-meeting-1. For more information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting View the meeting on Fedocal at: https://apps.fedoraproject.org/calendar/Fedora%20release/2019/10/17/#m9631 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce October 2019