F35 Change: Node.js 16.x by default (System-Wide Change proposal)
by Ben Cotton
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
2 years, 1 month
REMINDER: Fedora Linux 32 End of Life on 2021-05-25
by Ben Cotton
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
2 years, 1 month
Heads-up: RPM 4.17 alpha coming to rawhide near you
by Panu Matilainen
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 -
2 years, 1 month
F35 Change: CompilerPolicy Change (System-Wide Change proposal)
by Ben Cotton
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
2 years, 1 month
F34 Final Go/No-Go moved to Friday
by Ben Cotton
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
2 years, 1 month
Inactive packagers to be removed from their packages
by Pierre-Yves Chibon
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
2 years, 1 month
