Re: NeuroFedora review swaps
by Ankur Sinha
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
>
> > I'd like to get this package reviewed please:
> >
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> >
> > Would anyone like to swap reviews?
>
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
--
Thanks,
Regards,
Ankur Sinha
https://ankursinha.in
Time zone: Europe/London
3 years, 3 months
F34 Change proposal: Wayland by Default for KDE Plasma Desktop
(System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma
== Summary ==
Change the default session selection in SDDM to prefer the
Wayland-based KDE Plasma Desktop session over the X11-based one.
== Owner ==
* Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
[[User:Jgrulich|Jan Grulich]]
* Email: ngompa13(a)gmail.com, rdieter(a)gmail.com, jgrulich(a)redhat.com
* Product: KDE Spin
* Responsible WG: KDE SIG
== Detailed Description ==
With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
point where nearly all commonly used features in the desktop and all
major applications function in the Plasma Wayland environment on all
major GPUs (including NVIDIA with the proprietary driver). Starting
with Plasma 5.20 in Fedora 34, we will change the default
configuration for Wayland and X11 Plasma sessions so that Wayland is
preferred and used by default, while permitting the X11 session to be
selected as the alternative desktop environment option.
== Feedback ==
==== Is Wayland ready? ====
Wayland has been used by default for Fedora Workstation (which uses
GNOME) since Fedora 25. And while it was somewhat immature initially,
today it is a very rock-solid experience on virtually everything
Fedora Workstation runs on. The change in Fedora 25 kickstarted the
drive to get everything working on Wayland, and the Workstation team
succeeded beyond their wildest dreams. Firefox has been Wayland-native
by default since Fedora 31 as well.
On the KDE side, serious work into supporting Wayland started shortly
after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
much broader stack in its toolkit, and it has taken longer to get to a
usable state. With the Plasma 5.20 release, the Wayland protocol for
screencasting as well as middle-click paste finally are supported,
completing the required feature set for switching to Wayland by
default.
==== What about NVIDIA? ====
Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
driver on Wayland. It needs to be manually activated, which will be
taken care of by the <code>kwin-wayland-nvidia</code> package. So the
expectation is that all major GPUs will work just fine.
==== Why not keep using X11? ====
The fact of the matter is, Xorg is in
[https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstati...
"hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
development on it has basically stopped beyond the most critical of
fixes. Combined with the rapid maturation of the Wayland session in
KDE Plasma, this is the best time to make the switch and push things
over the edge for the KDE ecosystem in the same way that Fedora
Workstation did for the GNOME ecosystem.
== Benefit to Fedora ==
Fedora has long been a leader in advancing the adoption of the Wayland
protocol as part of the overall strategy to improve the Linux
graphical software stack. Much of the quality of Wayland for GNOME can
be attributed to the work done by the Fedora Workstation WG as part of
advancing the GNOME platform. It is now the KDE SIG's turn to do the
same for the KDE platform. By making this change, we are helping push
the adoption forward for newer, more streamlined, and overall more
actively developed graphics technology for the KDE ecosystem.
== Scope ==
* Proposal owners:
** Modify {{package|kwin}} to switch to Wayland
*** Split out <code>/usr/bin/kwin_x11</code> to the
<code>kwin-x11</code> subpackage.
*** Make {{package|kwin}} require <code>kwin-wayland</code> and
recommend <code>kwin-x11</code>
*** Add <code>kwin-wayland-nvidia</code> subpackage which contains
<code>/usr/lib/environment.d/10-kwin-wayland-nvidia.conf</code> to set
<code>$KWIN_DRM_USE_EGL_STREAMS</code> to <code>1</code>. This package
will have have a Supplements dependency <code>(kwin-wayland and
kmod-nvidia)</code>.
** Modify {{package|plasma-workspace}} to switch to Wayland
*** Rename <code>/usr/share/xsessions/plasma.desktop</code> to
<code>/usr/share/xsessions/plasma-xorg.desktop</code>, subpackage it
out as <code>plasma-workspace-xorg</code>, and have it require
<code>kwin-x11</code>
*** Rename <code>/usr/share/wayland-sessions/plasmawayland.desktop</code>
to <code>/usr/share/wayland-sessions/plasma.desktop</code>
*** Make {{package|plasma-workspace}} require
<code>plasma-workspace-wayland</code> and recommend
<code>plasma-workspace-xorg</code>
** Modify <code>@kde-desktop</code> comps group for Fedora 34 to
include <code>plasma-workspace-xorg</code> for the media.
* Other developers: N/A (not applicable for this Change)
* Release engineering: [https://pagure.io/releng/issue/9741 #9741]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not applicable for this Change)
== Upgrade/compatibility impact ==
Systems using certain (very old) graphics hardware or graphics drivers
(matrox, etc.) may have problems running the Wayland session. In these
(rare) cases, users may have to configure SDDM to use X11.
== How To Test ==
Log into a KDE Plasma desktop. Do any activity you would normally do
in your daily desktop use: launching applications, configuring
displays, etc. Things should work the same way under Wayland as they
used to under X.
== User Experience ==
The user experience should not change noticeably.
== Dependencies ==
This mainly affects the {{package|plasma-workspace}} and
{{package|kwin}} packages, and details for the changes for those
packages are described in the Scope section.
== Contingency Plan ==
* Contingency mechanism: Revert the file renames and switch
<code>plasma-workspace-xorg</code> to be the required package instead
of <code>plasma-workspace-wayland</code>
* Contingency deadline: beta freeze
* Blocks release? Yes
* Blocks product? KDE Spin
== Documentation ==
Some upstream documents about Wayland
* https://community.kde.org/Plasma/Wayland
* https://community.kde.org/KWin/Wayland
There is currently no coherent up to date documentation about Plasma Wayland.
== Release Notes ==
The KDE Plasma Desktop is using the Wayland display system now. X
applications will continue to run transparently through XWayland.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
%lua_requires behaves differently in F33+
by Michel Alexandre Salim
Hi,
Björn added some useful Lua packaging macros in
https://bugzilla.redhat.com/show_bug.cgi?id=1447324
One of them, %lua_requires, adds a dependency on either `lua(abi) =
%{lua_version}` or, on EL6 and below, on lua >= current version and lua
< next version.
Somehow this seems to be automatically applied on Fedora 33 and above
-- without adding any manual require on lua(abi)
e.g. lua-lunitx on Fedora 33
https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c23dc64c0
on Fedora 32, though, the macro is not automatically invoked (so the
update below is bad and I need to redo it)
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9074133de4
In fact, trying to use %lua_requires does not seem to work, with and
without curly braces:
error: line 15: Unknown tag: %lua_requires
error: line 15: Unknown tag: %{lua_requires}
Could someone help explain these two behaviors? I'm working on resuming
the Lua packaging draft so I want to have a canonical example on how
the macros are supposed to be used.
PS Björn -- we should consider moving the macros out of lua-devel and
into lua-rpm-macros, that lua-devel then depends on. That will fix the
inability to get these macros out to EPEL6 and EPEL7 - on those, lua
packages can just BR the macro package directly.
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
3 years, 4 months
Disabling Fedora 30 chroots in Copr
by Jakub Kadlcik
Hello,
we have just disabled Fedora 30 chroots in Copr.
According to the Fedora wiki [1], Fedora 30 reached the end of its life
on 2020-05-26 and therefore we are disabling it in Copr.
That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots:
- fedora-30-x86_64
- fedora-30-i386
- fedora-30-ppc64le
- fedora-30-aarch64
- fedora-30-armhfp
[1] https://fedoraproject.org/wiki/End_of_life
Jakub
3 years, 5 months
F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/CompressKernelFirmware
== Summary ==
Compress Kernel Firmwares to reduce on disk size
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: [mailto:pbrobinson@fedoraproject.org| pbrobinson(a)fedoraproject.org]
== Detailed Description ==
Since the linux 5.3 kernel there has been support for loading firmware
from xz compressed firmware. The upstream linux-firmware respository
is now over 900Mb, not including other kernel firmware that are in
Fedora but come from other sources. By compessing the firmware with
"xz -C crc32", the only option currently supported in the kernel, we
can reduce the ondisk size of the firmware by almost half.
== Benefit to Fedora ==
Reduced on disk size of the firmware used by the kernel.
== Scope ==
* Proposal owners:
** Add support upstream to the linux-firmware copy-firmware script to
compess the firmware and create the symlinks to the compressed
firmware
** Enable the upstream support in the Fedora linux-firmware package to
compress the firmware at build time
** Enable compressing firmware in packages that contain firmware used
by the kernel: eg alsa-sof-firmware, atmel-firmware, zd1211-firmware
** Enable the CONFIG_FW_LOADER_COMPRESS kernel option (long complete)
* Other developers:
** No impact
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There should be no upgrade impact, the support was added to the
generic firmware loader interface in the kernel.
== How To Test ==
Check devices that need firmware still work. Some devices that need
firmware include:
* GPU drivers such as nvidia, AMD and i915
* Wireless drivers such as those from Intel, Broadcom/Cyprus, TI,
Qualcomm and Marvel
* Wired network interfaces
* Storage drivers
* USB controllers and drivers
== User Experience ==
Generally users should notice little to no difference.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Don't compress kernel firmware
* Contingency deadline: GA
* Blocks release? No.
* Blocks product? No.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
Fedora 33 blocker status
by Ben Cotton
We've branched, so let's start the weekly blocker status email yayyyyy
Action summary
====================
Accepted blockers
-----------------
1. libreport — abrt-server errors when processing zstd compressed core
dumps produced by systemd-246~rc1-1.fc33 — POST
ACTION: abrt maintainers to make a new release containing the fix
2. resteasy — FreeIPA deployment fails in current Rawhide due to
various issues with Java 11 — NEW
ACTION: resteasy maintainers to diagnose issue and fix or pass the
buck as appropriate
3. sddm — login stuck when changing users repeatedly (log out, log in
a different one) — NEW
ACTION: sddm maintainers to diagnose issue and fix or pass the buck as
appropriate
4. selinux-policy — SELinux is preventing systemd-machine from
'create' accesses on the sock_file io.systemd.Machine. — POST
ACTION: selinux-policy maintainers to make a new release containing the fixes
5. tomcat — FreeIPA server deployment fails in
Fedora-Rawhide-20200714.n.0 — MODIFIED
ACTION: tomcat maintainers to investigate failed upgrade test
Proposed blockers
-----------------
1. gnome-shell — Network manager started stuck when I tries connecting
to VPN (openconnect) after upgrade gnome-shell to 3.37.1-1.fc33
version — NEW
ACTION: gnome-shell maintainers to diagnose issue
2. systemd — systemd-resolved.service not work with DNS server placed
behind VPN (openconnect) — NEW
ACTION: systemd maintainers to diagnose issue
3. udisks2 — zram-setup(a)zram0.service: Failed to load configuration:
No such file or directory — NEW
ACTION: Someone! to figure out why udisks2-zram gets pulled in
Bug-by-bug detail
=============
Accepted blockers
-----------------
1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST
abrt-server errors when processing zstd compressed core dumps produced
by systemd-246~rc1-1.fc33
abrt doesn't support core dumps compressed with zstd, which is now
used by systemd. Merged upstream PR uses libarchive to add support for
zstd (and other compression formats):
https://github.com/abrt/libreport/pull/656.
2. resteasy — https://bugzilla.redhat.com/show_bug.cgi?id=1866570 — NEW
FreeIPA deployment fails in current Rawhide due to various issues with Java 11
Deploying FreeIPA fails with a traceback in pki-tomcat. This appears
to be a dependency chain issue that (currently) ends at resteasy via
dogtag-pki. This may not be the last layer in the Java 11 onion.
3. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1861700 — NEW
login stuck when changing users repeatedly (log out, log in a different one)
This is now a blocker based on a recent approval-in-principle of a
release criterion related to logout and user switching. User processes
linger after logout which blocks logging in when another user has
logged in between the two sessions. Or when the second user logs back
in. Or when a single user logs in repeatedly. Using
KillUserProcesses=Yes helps the first problem, but raises on of its
own. It appears to be a race condition of some kind as the behavior is
not fully consistent.
4. selinux-policy — https://bugzilla.redhat.com/show_bug.cgi?id=1862686 — POST
SELinux is preventing systemd-machine from 'create' accesses on the
sock_file io.systemd.Machine.
librvirt VMs and systemd-machined service fail with AVC denials.
Merged upstream PRs should fix the denials mentioned in this bug:
https://github.com/fedora-selinux/selinux-policy/pull/405 and
https://github.com/fedora-selinux/selinux-policy/pull/407
5. tomcat — https://bugzilla.redhat.com/show_bug.cgi?id=1857043 — MODIFIED
FreeIPA server deployment fails in Fedora-Rawhide-20200714.n.0 due to
pki-tomcat failing to run with "java.lang.ClassNotFoundException:
org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource"
An upstream commit resulted in tomcat-coyote.jar missing packages. A
previous fix (FEDORA-2020-f897a68801) moved the goalposts.
tomcat-9.0.37-3 should fix this. Verification is blocked on BZ1866570,
but Adam's most recent upgrade test still fails with a
ClassNotFoundException for
com.sun.xml.internal.bind.v2.ContextFactory.
Proposed blockers
-----------------
1. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1830343 — NEW
Network manager started stuck when I tries connecting to VPN
(openconnect) after upgrade gnome-shell to 3.37.1-1.fc33 version
Connecting to an OpenConnect VPN using 2FA hangs after the second
factor is entered. The journal contains an array.toString() message
which may or may not be a red herring (it looks like a deprecation
warning).
2. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=1863041 — NEW
systemd-resolved.service not work with DNS server placed behind VPN
(openconnect)
When connected to an OpenConnect VPN, host name resolution fails.
Manually disabling the systemd-resolved service works around this
issue.
3. udisks2 — https://bugzilla.redhat.com/show_bug.cgi?id=1861463 — NEW
zram-setup(a)zram0.service: Failed to load configuration: No such file
or directory
Installation on armhfp and aarch64 single-board computers fails with
zram-setup errors. It appears to be a conflict betwen udisks2-zram and
zram-generator-defaults. Update FEDORA-2020-e143a283fb renamse the
service unit file to make its origin more obvious. Removing
udisks2-zram fixes the issue, but it's pulled in as a dependency of
something, so that needs to be identified.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
CPE Weekly: 2020-09-20
by Aoife Moloney
Hi Everyone,
Below is this week's CPE weekly for week ending 2020-09-20.
I found that if you want to skip to the hackmd, you can use the view
link https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view and then use the
header bar on your left to skip to either the Fedora or CentOS
updates, whichever interest you.
I'll also be adjusting these updates in the coming weeks to make them
a bit more direct to consume. Thanks for giving me this feedback in
the CPE survey, I want to deliver value to you all, so it's great to
KNOW what you find valuable first hand :)
# CPE Weekly: 2020-08-14
## General Project Updates
As a reminder, below are the projects the CPE team are working on for
the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas
We have recently held our Q4 planning session and the CPE review team,
Fedora, CentOS and RHEL BU have voted the following projects for
action in Q4, which is the months of October November & December:
* OSBS for aarch64
* Fedora-messaging schemas
We are continuing to work on CentOS Stream and Noggin and took these
projects as confirmed when looking at what other work our team could
realistically complete in the Q4 period, given that there's both
Thanksgiving and Christmas time off to consider, plus any time off our
team wishes to take.
The taiga cards of Noggin, CentOS Stream, OSBS for aarch64 and
fedora-messaging schemas will be updated next week with what our team
hopes to deliver in the next quarter on each of the projects.
Our project board is here (it's just not updated properly - yet)
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null
### Misc
#### GitLab
Thank you so much to everyone for adding your questions to the doc for
the GitLab AMA session on Thursday 10th September, and for your
attendance on the day during the call.
Here is the full AMA transcript
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
however it is a bit confusing to read so we got a few great
suggestions to have dedicted topics like Message Bus and Branching,
etc go out to the devel lists to discuss. I'm happy to start this next
week, but I will collect the questions related to each topic and
propose a cadence to send them out first to discuss, so people dont
miss mails and know the week ending 2nd October will be (for example)
the topic of Group Permissions - What do you think?
GitLab have also agreed to answer the questions, we have asked them to
do so within 2 weeks of the AMA so as soon as this is complete I will
let you know so you can read through them on the hackmd link.
The link is here where we asked you to contribute your questions and I
will be posting answers once we have them underneath
https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
I really appreciate your involvement with this as we begin to dig
deeper into how this might play out next year and what way it should
for everyone's benefit.
## Project Updates
*The below updates are pulled directly from our CPE team call we have
every week.*
## Fedora
### General
* 6 of 8 Beta-blockers have fixes for F33 beta
* New release of fedscm_admin
* FMW mac and windows binaries are signed
### Staging Environment
* About 70% done installing vm’s (27 left out of 88)
* Still need to bring up aarch64/armv7/ppc64le builders
* Databases need syncing
### AAA Replacement
* The team are working on testing Ipsilon in Staging and adding OpenID
Connect Capability
* they are also testing fas2ipa migration script in tiny-stage and improve it
* Add Noggin to tiny-stage environment and test
* The teams kanban board where they track their work can be found here
https://github.com/orgs/fedora-infra/projects/6
### Fedora Messaging Schemas
* This project is on hold until Noggin completes.
* It will be resumed around December timeframe and is part of our Q4
workload to complete
* There is a list of applications that require messaging schemas can
be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit
* There is a readme which contains documentation on messaging schemas,
a cookie-cutter template to create the schema and a definition of Done
for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7
### Packager Workflow Healthcare
* The team have been working on more improvements and fixes to the
monitor-gating
* These improvements have led to
* Finding a bug in our testing script
* Improved log messages
* We actually caught a problem! :)
* The data the team have been reviewing have been from April - July
and have already discovered that so far it looks like Pagure, koji and
bodhi work well
* We see some intermittent problems, but nothing too big, mostly
only spikes in runtime
* Fedora CI still looks like a POC, but functional
* Our test-script hitting timeouts/failing 10% of the time
* Gating (greenwave/resultsdb/waiverdb) looks functional, but
relies on CI and doesn't have as much packages going through the
workflow
* A more formal report will be published soon as part of the project
deliverable so keep an eye on their work!
* The teams work is being tracked here
https://teams.fedoraproject.org/project/cpe-cicd/kanban
## CentOS Updates
### CentOS
* Deployed new 4.5.9 openshift cluster for Stream
* The team provisioned EC2 infra for team responsible for
registry.centos.org (we don’t maintain it, so just providing infra,
like Fedora does for Copr)
* They also migrated a bunch of nodes to the new Ansible CI inventory
### CentOS Stream
* Using Openshift cluster for engineering work and will be using it to
deploy & test mbbox in our infra
* Scoping and refining work for October November & December
## Team Info
### Changes to CPE Product Owner Office Hours
Following the feedback received in the CPE survey, I will be reducing
my IRC office hours to once per month.
#### #fedora-meeting-1
* Next Meeting: 2020-10-15 @ 1300 UTC on #fedora-meeting-1
#### #centos-meeting
* Next Meeting: 2020-10-13 @ 1500 UTC on #centos-meeting
## Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.
See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/
As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.
Have a great week!
Aoife
Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
3 years, 6 months
Unresponsive packagers: ekulik, imcleod and lsun
by Pierre-Yves Chibon
Good Morning Everyone,
Since September 5th, we have been emailing daily the following users to notify
that the email they have set in FAS does not correspond to a valid bugzilla
account.
This is a requirement for Fedora packagers.
Does someone know how to contact these people?
ekulik is main admin of modules/pg-semver
ekulik has a bugzilla override on modules/pg-semver
ekulik is maintainer of rpms/abrt
ekulik is maintainer of rpms/abrt-addon-python3
ekulik is maintainer of rpms/abrt-java-connector
ekulik is maintainer of rpms/abrt-server-info-page
ekulik is maintainer of rpms/container-exception-logger
ekulik is maintainer of rpms/gnome-abrt
ekulik is maintainer of rpms/libreport
ekulik is maintainer of rpms/meson
ekulik is maintainer of rpms/pg-semver
ekulik is maintainer of rpms/python-ratelimitingfilter
ekulik is main admin of rpms/python-satyr
ekulik is maintainer of rpms/python-testing.postgresql
ekulik is main admin of rpms/reportd
ekulik is maintainer of rpms/retrace-server
ekulik is maintainer of rpms/satyr
ekulik is maintainer of rpms/will-crash
ekulik is main admin of rpms/winetricks
ekulik has a bugzilla override on rpms/winetricks
imcleod is maintainer of rpms/VMDKstream
imcleod has a bugzilla override on rpms/VMDKstream
imcleod is main admin of rpms/imagefactory
imcleod has a bugzilla override on rpms/imagefactory
imcleod is main admin of rpms/imagefactory-plugins
imcleod has a bugzilla override on rpms/imagefactory-plugins
imcleod is maintainer of rpms/oz
imcleod is maintainer of rpms/python-cloudservers
imcleod is maintainer of rpms/python-prettytable
imcleod is maintainer of rpms/python-psphere
imcleod has a bugzilla override on rpms/python-psphere
imcleod is main admin of rpms/python-pyrax
imcleod has a bugzilla override on rpms/python-pyrax
lsun is main admin of rpms/rshim
lsun has a bugzilla override on rpms/rshim
Thanks for your help,
Pierre
3 years, 6 months