devel-announce April 2021

devel-announce@lists.fedoraproject.org

7 participants
19 discussions

F35 Change: Node.js 16.x by default (System-Wide Change proposal)
by Ben Cotton 29 Apr '21

29 Apr '21

https://fedoraproject.org/wiki/Changes/Nodejs16 == Summary == The latest release of Node.js to carry a 30-month lifecycle is the 16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35 will carry 16.x as the default Node.js interpreter for the system. The 14.x and 12.x interpreters will remain available as non-default module streams. == Owner == * Name: [[User:zvetlik| Zuzana Svetlikova]] * Email: zsvetlik(a)redhat.com * Name: [[User:Sgallagh| Stephen Gallagher]] * Email: sgallagh(a)fedoraproject.org * Responsible SIG: Node.js SIG == Detailed Description == Fedora 35 will ship with the latest LTS version of Node.js. '''dnf install nodejs''' will give users nodejs-16.x and the matching npm package. == Benefit to Fedora == Node.js is a popular server-side JavaScript engine. Keeping Fedora on the latest release allows us to continue tracking the state-of-the-art in that space. For those whose applications do not yet work with the 16.x release, Fedora 35 will also have the 14.x and 12.x releases available as selectable module streams. == Scope == * Proposal owners: The packages are already built for Fedora 33, 34 and 35 in a non-default module stream. On June 14th, 2021, the nodejs-16.x packages will be built in the non-modular repository and thus become the default in Fedora 35. * Other developers: Any developer with a package that depends on Node.js at run-time or build-time should test with the 16.x module stream enabled as soon as possible. Issues should be reported to nodejs(a)lists.fedoraproject.org * Release engineering: We will coordinate with the Node.js SIG to create a side-tag to perform the rebuilds before making 16.x the default. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == As with previous releases, users running Fedora 33 or Fedora 34 with the non-modular nodejs-14.x packages will be automatically upgraded to the 16.x packages when they upgrade to Fedora 35, which may cause issues. If users are running software known not to support Node.js 16.x yet, they can switch the system to use 14.x with '''dnf module''' commands. == How To Test == * Confirm that `dnf install nodejs` results in Node.js 16.x being installed. * Confirm that upgrading from Fedora 33 or Fedora 34 with nodejs-14.x installed (non-modular) results in an upgrade to nodejs-16.x * Confirm that upgrading from Fedora 33 or Fedora 34 with the `nodejs:14` module enabled does *not* result in an upgrade to 16.x and still has `nodejs:14` enabled on Fedora 35. * Confirm that upgrading from Fedora 33 or Fedora 34 with the `nodejs:16` module enabled upgrades successfully and still has `nodejs:16` enabled on Fedora 33. == User Experience == Users will have the 16.x release of Node.js available by default. See the "Upgrade/compatibility impact" section for specific details. == Dependencies == All packages prefixed with `nodejs-` depend on this package. If they do not work with Node.js 16.x, they will need to be updated, made modular and dependent upon the `nodejs:14` stream or else removed from Fedora 35. Prior to the switchover date to Node.js 16.x as the default, packagers are strongly encouraged to test their existing Node modules with 16.x via the Modular version by running: <pre> dnf module reset nodejs dnf module install nodejs:16/development </pre> Packagers can also test their builds using `mock` by creating the file `/etc/mock/fedora-rawhide-x86_64-nodejs16.cfg` with the following contents: <pre> config_opts['target_arch'] = 'x86_64' config_opts['legal_host_arches'] = ('x86_64',) config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular'] config_opts['module_install'] = ['nodejs:16/development'] include('templates/fedora-rawhide.tpl') </pre> Then call <pre> mock -r fedora-rawhide-x86_64-nodejs16 --enablerepo=rawhide-modular nodejs-foo </pre> (Note that the `--enablerepo=rawhide-modular` portion looks redundant, but this is because of [https://github.com/rpm-software-management/mock/issues/591 a mock bug]) == Contingency Plan == * Contingency mechanism: Revert to Node.js 14.x as the default Node.js interpreter. This will require bumping epoch. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? No == Documentation == * https://nodejs.org/dist/latest-v16.x/docs/api/ * https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V16.md == Release Notes == Fedora 35 now ships with Node.js 16.x as the default Node.js JavaScript server-side engine. If your applications are not yet ready for this newer version, you can revert to the 14.x series by running the following commands <pre> dnf remove nodejs dnf module reset nodejs dnf module install nodejs:14 </pre> -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

REMINDER: Fedora Linux 32 End of Life on 2021-05-25
by Ben Cotton 29 Apr '21

29 Apr '21

Fedora Linux 32 will reach EOL on Tuesday 25 May 2021. On this day, we will close all of the F32 bugs which remain open. You have a few weeks remaining to submit updates, if you have any, before the Fedora 32 release becomes unsupported. As a reminder, updates that are still in testing when EOL is reached will not be pushed to stable. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

FESCo nominations now open
by Ben Cotton 28 Apr '21

28 Apr '21

Now through 12 May, you may nominate candidates for the four open seats on the Fedora Engineering Steering Committee. To nominate yourself (or others, if you check with them first), visit: https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations FESCo is currently selecting the questions for the interview questionnaire, which will be finalized before the beginning of the interview period. For more information, see the Community Blog post: https://communityblog.fedoraproject.org/f34-elections-nominations-now-open/ -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora Linux 34 is available now!
by Matthew Miller 27 Apr '21

27 Apr '21

I'm excited to announce the official release of Fedora Linux 34! The beta version has been very popular this time around, so I know you are excited too. Please join me in thanking the thousands of people who work in the Fedora Project every year and who make this amazing collaborative community operating system possible. Fedora friends: you are awesome, and because of you Fedora Linux 34 is as well. Read the official announcement at: * https://fedoramagazine.org/announcing-fedora-34 or just go ahead and upgrade your system, or download install media from: * https://getfedora.org/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader _______________________________________________ announce mailing list -- announce(a)lists.fedoraproject.org To unsubscribe send an email to announce-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/announce@lists.fedoraproject.… _______________________________________________ announce mailing list -- announce(a)lists.fedoraproject.org To unsubscribe send an email to 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/announce@lists.fedoraproject.… _______________________________________________ announce mailing list -- announce(a)lists.fedoraproject.org To unsubscribe send an email to 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/announce@lists.fedoraproject.… _______________________________________________ announce mailing list -- announce(a)lists.fedoraproject.org To unsubscribe send an email to 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/announce@lists.fedoraproject.…

1 0

Heads-up: RPM 4.17 alpha coming to rawhide near you
by Panu Matilainen 26 Apr '21

26 Apr '21

It's spring, it's raining sleet where I live, and it's also the season for new rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17. The changes to the macro subsystem internals have been quite large, and while it's supposed to be backwards compatible with changes this big it'd be foolish not to expect some amount of the unexpected. So please pay attention, and don't be shy about filing bugs. One known issue is java-11-openjdk updates failing with a message like this: > error: lua script failed: /usr/libexec/copy_jdk_configs.lua:43: attempt to index a nil value (global 'arg') That is already reported against the java packages as https://bugzilla.redhat.com/show_bug.cgi?id=1892224, please don't file duplicates on that. It needs to be addressed in the java packaging. For more details, see upstream release notes at https://rpm.org/wiki/Releases/4.17.0 Have fun, - Panu -

1 0

Fedora Linux 34 Final is GO
by Ben Cotton 23 Apr '21

23 Apr '21

The Fedora 34 Final RC1.2 compose [1] is GO and will be shipped live on Tuesday, 27 April 2021. For more information please check the Go/No-Go meeting minutes [2] or logs [3]. Thank you to everyone who has worked on this on-time release. [1] https://dl.fedoraproject.org/pub/alt/stage/34_RC-1.2/ [2] https://meetbot.fedoraproject.org/fedora-meeting-1/2021-04-23/f34-final-go_… [3] https://meetbot.fedoraproject.org/fedora-meeting-1/2021-04-23/f34-final-go_… -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

F35 Change: CompilerPolicy Change (System-Wide Change proposal)
by Ben Cotton 23 Apr '21

23 Apr '21

https://fedoraproject.org/wiki/Changes/CompilerPolicy == Summary == Fedora has historically forced packages to build with GCC unless the upstream project for the package only supported Clang/LLVM. This change proposal replaces that policy with one where, given a good technical reason, a packager may: * Choose to build with their package with clang even if the upstream project supports gcc. * Choose to build with gcc even if upstream does not support it. The goal is to give the packager the ability to use their own technical judgement to choose the best compiler. Note this change is only for compiler selection. It does not change existing policies WRT runtime library selection, linker selection, debuggers, etc. == Owner == * Name: Jeff Law * Name: Tom Stellard * Email: tstellar(a)redhat.com == Detailed Description == The main goal here is to give a packager some freedom to select the best compiler for their package. This policy change will allow packagers to choose to use a non-default compiler for their package, if they have a valid technical reason to do so. The default compiler for Fedora is gcc or when upstream doesn't support gcc, then the default compiler is clang. Examples of valid technical reasons to not use the default compiler, include but are not limited to: * The default compiler cannot build a package correctly. * The packager needs to disable a compiler feature (e.g. LTO) in order for the default compiler to correctly compile their package. * The default compiler takes significantly longer to build a package. * The default compiler is missing a feature that would benefit the package. If this policy is implemented, it may be beneficial for packagers to use conditional macros to switch between different compilers. This could be useful when trying to make a comparison between the two compilers or to make it easy to change back to the default compiler. Therefore, in addition to updating the compiler policy, we are also proposing to add the following macros to redhat-rpm-config to help facilitate easily switching between different compilers: The new macros are: * %cc - equivalent to %__cc (C Compiler) * %cxx - equivalent to %__cxx (C++ Compiler) * %cpp - equivalent to %_cpp (C preprocessor) The policy update will also recommend that packagers use standardized macro names when using conditional options to control the compiler choice: %bcond_with toolchain_clang %bcond_with toolchain_gcc [https://pagure.io/packaging-committee/pull-request/1066 Pull request] with proposed policy changes. Note this change is only for compiler selection. It does not change existing policies WRT runtime library selection, linker selection, debuggers, etc. It is worth noting that Clang/LLVM's implementation of -fstack-clash-protection, which is one of Fedora's default compiler flags, is under development and does not yet have an implementation for AArch64. == Feedback == * The original proposal stated that Fedora packagers should follow upstream's compiler preferences, but based on feedback, the proposal was updated to allow a packager to choose the compiler they feel is best as long as there is a valid technical reason to do so. == Benefit to Fedora == This change allows packagers more freedom to use the compiler that produces the best version of their package, which helps to give our users a better overall experience. Also, giving package maintainers more freedom to select the best compiler, let's them spend more time focusing on package improvements and less time on debugging compiler issues. An example of a package that could benefit from this policy is Firefox. Upstream, the Firefox project builds primarily with Clang/LLVM. Yet we force the Fedora package owner to find and fix issues building with GCC then either carry those custom fixes forward in Fedora or negotiate with upstream to get those changes upstreamed. While this process can be helpful in finding non-portable code, this is ultimately a poor use of the packager's time. Additionally Fedora loses the benefit of the testing provided by other distributions where Firefox is compiled in the same way as the upstream project -- when issues arise the Fedora team must consider the possibility that the problem is due to using GCC instead of Clang/LLVM or the patches to make that possible. Again, this is a poor use of Fedora developer's time. Other packages that may benefit include: * llvm/clang (currently has to disable LTO due to compilation failures). * qemu (could take advantage of clang's CFI hardening feature). == Scope == * Proposal owners: ** Update the Fedora Packaging Guidelines to reflect the policy change and submit patch with new macros to redhat-rpm-config. * Other developers: ** Developers that want to use a new compiler in accordance with the policy may update their packages if they want, but there is no required action for packagers with this change. * Release engineering: [https://pagure.io/releng/issue/9503] (a check of an impact with Release Engineering is needed) ** I do not believe this change requires any coordination with release engineering. No mass rebuild is required. * Policies and guidelines: ** Yes, the packaging guidelines certainly need to be updated for this feature. That can happen as soon as the exact text is agreed upon. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This should not require any configuration changes or data migration, nor should it change existing functionality. == How To Test == For packages where the compiler should change, the package owner will need to update the spec file and build the package with the new compiler. Once done, the package's testsuite should be run (if it's not part of the standard build process). In general, I would think the standard Fedora QE work should be sufficient here, perhaps with a bit of additional attention to the affected packages. The graphical nature of some of the potentially affected packages like Firefox and Chrome will make testing difficult on some of Fedora's architectures. == User Experience == Users should not notice any change. == Dependencies == There are no dependencies, once the policy change is made, if packagers choose to update their packages, they can do it at any time. == Contingency Plan == The backup plan is trivial. We can keep the current policy in place. * Contingency mechanism: ** It seems like we could institute the policy change anytime we choose. But it also seems like once the policy change is in place, packages that are going to convert should do so before beta freeze. * Contingency deadline: Fedora can ship with this feature in an incomplete state. * Blocks release? No * Blocks product? N/A == Documentation == Several years ago Red Hat's tools team championed for Fedora policy to strongly discourage the use of LLVM/Clang for package building. Exceptions were made for packages that could only be built with Clang/LLVM: https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler At that point in history Red Hat had no Clang/LLVM engineers or expertise. In fact, the LLVM packages were actually maintained by an engineer on the desktop team (they had a hard requirement for llvm-pipe, so they got to own the Clang/LLVM bits). The policy essentially was a risk management strategy for Fedora. Times have changed and as a result we should revisit that Fedora policy. The Red Hat tools team believes that LLVM/Clang and GCC should be considered equals from a Fedora policy standpoint. Selection of one toolchain over the other should be driven by the packager's preferences not by Fedora specific policy. The only policy restriction should be that the compiler must exist in Fedora. == Release Notes == This change should not have any end user impacts nor does it strictly require a release note. However, a short release note could be written if FESCO or the development community thinks it would be useful. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

F34 Final Go/No-Go moved to Friday
by Ben Cotton 21 Apr '21

21 Apr '21

Hi everyone, Since we anticipate a Fedora Linux 34 release candidate request today, I am moving the Go/No-Go meeting from Thursday to Friday. This will allow the QA team more time to perform validation tests. The Fedora Linux 34 Final Go/No-Go[1] meeting is scheduled for Friday 23 April at 1700 UTC in #fedora-meeting-1. At this time, we will determine the status of F34 for the 27 April target date. For more information about the Go/No-Go meeting, see the wiki[2]. [1] https://calendar.fedoraproject.org/meeting/9969/ [2] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Inactive packagers to be removed from their packages
by Pierre-Yves Chibon 16 Apr '21

16 Apr '21

Good Morning Everyone, When we rolled out the new AAA solution a few weeks ago, some accounts have not been migrated: - Accounts that have been set inactive by their owner - Accounts that are disabled - Accounts marked as spam This resulted in some packager accounts not being migrated. As a consequence, since then, the script that syncs the default-assignee and CC list for each component from dist-git to bugzilla has been notifying us about a list of packagers in dist-git that could not be synced to bugzilla due to a lack of bugzilla account (or rather, in this case, the lack of Fedora account). Since these accounts do not exist in the new FAS, I will be removing them from their packages on dist-git. Here is the list of account impacted: - amukunda - brolley - dp67 - ianweller - jensm - jima - jjmcd - juanmabc - kmatsui - kurtseifried - marcusk - rnorwood - sindrepb - splinux - vvitek I am planning on removing these users on April 20th. If anyone is opposed to this, please let me know. At the bottom of this email is the list of component affected for each of these users. Thanks, Pierre ------------------- amukunda is maintainer of rpms/java-atk-wrapper brolley is maintainer of rpms/si-units brolley is watching rpms/systemtap brolley is maintainer of rpms/uom-lib brolley is maintainer of rpms/uom-parent brolley is maintainer of rpms/uom-systems dp67 is watching rpms/HamFax dp67 is watching rpms/ax25-apps dp67 is watching rpms/cwirc dp67 is maintainer of rpms/demorse dp67 is watching rpms/dxcc dp67 is watching rpms/gmfsk dp67 is watching rpms/gpsk31 dp67 is maintainer of rpms/gpsman dp67 is maintainer of rpms/gridloc dp67 is maintainer of rpms/linpsk dp67 is watching rpms/lpsk31 dp67 is watching rpms/xgridloc dp67 is maintainer of rpms/xpsk31 ianweller is watching rpms/abattis-cantarell-fonts ianweller is maintainer of rpms/datagrepper ianweller is watching rpms/ezstream ianweller is watching rpms/fedora-business-cards ianweller is watching rpms/gnome-gmail-notifier ianweller is watching rpms/irclog2html ianweller is watching rpms/lordsawar ianweller is watching rpms/mediawiki-CategoryTree ianweller is watching rpms/mediawiki-HTTP302Found ianweller is maintainer of rpms/mediawiki-ParserFunctions ianweller has a bugzilla override on rpms/mediawiki-ParserFunctions ianweller is main admin of rpms/mediawiki116-Cite ianweller has a bugzilla override on rpms/mediawiki116-Cite ianweller is main admin of rpms/mediawiki116-ParserFunctions ianweller has a bugzilla override on rpms/mediawiki116-ParserFunctions ianweller is watching rpms/odfpy ianweller is watching rpms/openarena ianweller is maintainer of rpms/python-backports-lzma ianweller is maintainer of rpms/python-backports-ssl_match_hostname ianweller is maintainer of rpms/python-fedmsg-meta-debian ianweller is maintainer of rpms/python-fedmsg-meta-fedora-infrastructure ianweller is watching rpms/python-flask ianweller is watching rpms/python-flickrapi ianweller is watching rpms/python-simplemediawiki ianweller is main admin of rpms/python-sqlite3dbm ianweller has a bugzilla override on rpms/python-sqlite3dbm ianweller is watching rpms/python-transitfeed ianweller is watching rpms/python-werkzeug ianweller is watching rpms/rsstool ianweller is main admin of rpms/supybot-fedora ianweller is watching rpms/techtalk-pse ianweller is watching rpms/wordpress-plugin-add-to-any ianweller is watching rpms/wordpress-plugin-add-to-any-subscribe jensm is watching rpms/callgit jensm is watching rpms/perl-Ham-Reference-QRZ jensm is maintainer of rpms/pisg jima is maintainer of rpms/alpine jima is watching rpms/alsa-oss jima is watching rpms/aoetools jima is watching rpms/banner jima is watching rpms/bwm-ng jima is maintainer of rpms/clusterssh jima is watching rpms/conserver jima is watching rpms/dnsmasq jima is watching rpms/graphviz jima is watching rpms/libdnet jima is watching rpms/libstatgrab jima is watching rpms/miau jima is watching rpms/ngrep jima is maintainer of rpms/perl-Device-SerialPort jima is maintainer of rpms/perl-X11-Protocol jima is watching rpms/prtconf jima is watching rpms/putty jima is watching rpms/rblcheck jima is watching rpms/scanssh jima is watching rpms/silo jima is watching rpms/vblade jima is watching rpms/videodog jima is watching rpms/xorg-x11-drv-sunbw2 jima is watching rpms/xorg-x11-drv-suncg14 jima is watching rpms/xorg-x11-drv-suncg3 jima is watching rpms/xorg-x11-drv-suncg6 jima is watching rpms/xorg-x11-drv-sunffb jima is watching rpms/xorg-x11-drv-sunleo jima is watching rpms/xorg-x11-drv-suntcx jjmcd is main admin of rpms/R-qcc jjmcd has a bugzilla override on rpms/R-qcc jjmcd is main admin of rpms/rcrpanel jjmcd has a bugzilla override on rpms/rcrpanel juanmabc is main admin of rpms/mkproject juanmabc has a bugzilla override on rpms/mkproject juanmabc is main admin of rpms/rf juanmabc has a bugzilla override on rpms/rf juanmabc is main admin of rpms/tw juanmabc has a bugzilla override on rpms/tw kmatsui is main admin of rpms/mcpp kmatsui has a bugzilla override on rpms/mcpp kurtseifried is watching rpms/php-pear-Auth-OpenID marcusk is watching rpms/PyXB marcusk is watching rpms/Pyrex marcusk is watching rpms/eventlog marcusk has a bugzilla override on rpms/eventlog marcusk is watching rpms/exonerate marcusk is watching rpms/gnu-smalltalk marcusk is watching rpms/ivykis marcusk is watching rpms/mailgraph marcusk is watching rpms/menulibre marcusk is watching rpms/pykka marcusk is watching rpms/python-py2neo marcusk is watching rpms/syslog-ng rnorwood is watching rpms/crcimg rnorwood is maintainer of rpms/gnome-nettool rnorwood is watching rpms/libnoise rnorwood is watching rpms/mathmap rnorwood is watching rpms/olpc-netutils rnorwood is maintainer of rpms/perl-Inline rnorwood is maintainer of rpms/perl-Inline-Files rnorwood is maintainer of rpms/perl-PDL rnorwood is maintainer of rpms/perl-Pod-Escapes rnorwood is maintainer of rpms/perl-Pod-Simple rnorwood is watching rpms/puritan rnorwood is watching rpms/pyevent rnorwood is watching rpms/vorbis-tools rnorwood is maintainer of rpms/vte rnorwood is watching rpms/xmms-pulse sindrepb is watching rpms/DMitry sindrepb is watching rpms/alacarte sindrepb is watching rpms/arp-scan sindrepb is watching rpms/avant-window-navigator sindrepb is watching rpms/awn-extras-applets sindrepb is watching rpms/ax25-apps sindrepb is watching rpms/ax25-tools sindrepb is watching rpms/blam sindrepb is watching rpms/bottlerocket sindrepb is watching rpms/clearlooks-compact-gnome-theme sindrepb is watching rpms/colrdx sindrepb is watching rpms/cowbell sindrepb is watching rpms/demorse sindrepb is watching rpms/firewalk sindrepb is watching rpms/flac123 sindrepb is watching rpms/gnome-do sindrepb is watching rpms/gpsk31 sindrepb is watching rpms/gtk-recordmydesktop sindrepb is watching rpms/gtranslator sindrepb is watching rpms/halberd sindrepb is watching rpms/hamlib sindrepb is watching rpms/httptunnel sindrepb is watching rpms/ike-scan sindrepb is watching rpms/muine sindrepb is watching rpms/muine-scrobbler sindrepb is watching rpms/nbtscan sindrepb is watching rpms/nikto sindrepb is watching rpms/notify-sharp sindrepb is watching rpms/nrg2iso sindrepb is watching rpms/onesixtyone sindrepb is watching rpms/perl-Class-Gomor sindrepb is watching rpms/perl-DBIx-SQLite-Simple sindrepb is watching rpms/perl-Math-Base85 sindrepb is watching rpms/perl-Net-IPv4Addr sindrepb is watching rpms/perl-Net-IPv6Addr sindrepb is watching rpms/perl-Net-Libdnet sindrepb is watching rpms/perl-Net-Packet sindrepb is watching rpms/perl-Net-Packet-Target sindrepb is watching rpms/perl-Net-Pcap sindrepb is watching rpms/perl-Net-Write sindrepb is watching rpms/perl-Nmap-Parser sindrepb is watching rpms/perl-SQLite-Simple sindrepb is watching rpms/perl-libwhisker2 sindrepb is watching rpms/pisg sindrepb is watching rpms/pychess sindrepb is watching rpms/python-imdb sindrepb is watching rpms/python-musicbrainz2 sindrepb is watching rpms/python-virtkey sindrepb is watching rpms/pyxdg sindrepb is watching rpms/qt-recordmydesktop sindrepb is watching rpms/recordmydesktop sindrepb is watching rpms/rubyripper sindrepb is watching rpms/scratchpad sindrepb is watching rpms/serpentine sindrepb is watching rpms/smeg sindrepb is watching rpms/solfege sindrepb is watching rpms/tcptraceroute sindrepb is watching rpms/telepathy-mission-control sindrepb is watching rpms/txt2man sindrepb is watching rpms/vttest sindrepb is watching rpms/xdotool sindrepb is watching rpms/xdx sindrepb is watching rpms/xfhell splinux is watching rpms/cdf splinux is watching rpms/crun splinux is watching rpms/drapes splinux is maintainer of rpms/fbpanel splinux has a bugzilla override on rpms/fbpanel splinux is watching rpms/firestarter splinux is watching rpms/gconf-cleaner splinux is watching rpms/gdmap splinux is watching rpms/gfa splinux is maintainer of rpms/gkrellm splinux is watching rpms/glipper splinux is watching rpms/gnome-specimen splinux is watching rpms/gnubiff splinux is watching rpms/gstm splinux is watching rpms/libgtksourceviewmm splinux is watching rpms/macchanger splinux is main admin of rpms/musca splinux has a bugzilla override on rpms/musca splinux is watching rpms/musicbox splinux is watching rpms/notecase splinux is maintainer of rpms/obconf splinux is maintainer of rpms/openbox splinux is maintainer of rpms/pekwm splinux is watching rpms/pessulus vvitek is watching rpms/fcron vvitek is watching rpms/gzip vvitek is maintainer of rpms/less vvitek is watching rpms/pmount vvitek is watching rpms/rdist vvitek is maintainer of rpms/rsync vvitek is maintainer of rpms/sed vvitek is watching rpms/unzip vvitek is watching rpms/zip

1 0

Fedora Linux 34 Final is NO-GO
by Ben Cotton 14 Apr '21

14 Apr '21

Due to outstanding blocker bugs[1], we do not have a release candidate for Fedora Linux 34. Tomorrow's Go/No-Go meeting is cancelled. The next Fedora Linux 34 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 22 April in #fedora-meeting-1. We will aim for the "target date #1" milestone of 27 April. The release schedule[3] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/34/final/buglist [2] https://calendar.fedoraproject.org/meeting/9957/?from_date=2021-04-22 [3] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce April 2021