[COPR] Build against libuv and Judy librairies
by Didier Fabert
Hi,
I try to make an epel-8 package on COPR, and I get the following errors
in root.log
DEBUG util.py:634: No matching package to install: 'Judy-devel'
DEBUG util.py:634: No matching package to install: 'libuv-devel'
It's working as expected on Koji.
AM I missing something in my conf ?
Best Regards,
Didier FABERT.
3 years, 5 months
Retiring xkbevd, xkbprint, xkbutils
by Peter Hutterer
As part of the XorgUtilityDeaggregation [1], I'm planning to retire these
three. They're currently part of xorg-x11-xkb-utils-extras, a subpackage of
xorg-x11-xkb-utils (which provides setxkbmap and xkbcomp).
setxkbmap and xkbcomp will be split into their own packages and both will
Obsolete: xorg-x11-xkb-utils.
tigervnc [2] and x2goserver [3] still need to have their Requires fixed, but
otherwise we're good to go here, I think.
For the other three packages, I don't think it's worth the effort of
creating new packages for them:
- xkbprint: one upstream bug report in the last 7 years
- xkbevd: no upstream bug reports
- xkbwatch: one bug report two years ago but with lack of reviewers and
motivation of the reporter it fizzled out
Upstream development is zero except for the usual janitorial patches that
apply to all xorg packages (like the gitlab switch).
So, right now my plan is to simply retire the xorg-x11-xkb-utils package
once xkbcomp/setxkbmap are avilable and let these three packages descend
into oblivion. They can be resurrected by a willing maintainer as separate
packages if need be.
If that doesn't work for some reason, please speak up now.
Cheers,
Peter
[1] https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894787
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1894794
3 years, 5 months
GitLab AMA Topic Discussion: Permissions & Access
by Aoife Moloney
Hi everyone,
Thanks again for your involvement in the GitLab AMA session on IRC in
September. As promised, this is the first of a 5-part series breaking
down main topics that came up during the session. I will send a topic
every week for discussion to both Fedora and CentOS devel lists. I
have pulled the relevant questions and answers from the original
hackmd doc into one email. If you would like to discuss this topic
specifically, here might be a good place to do so. I dont consider
myself technical enough to weigh in on details, but I am happy to
facilitate as best I can via email. And more importantly (for me),
learn from the discussion too.
Here are some links to resources as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
* AMA Blog post
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
* Here is this email in hackmd if you wish to view it there:
https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view
## Topic: Permission and Access
- Question: Fedora has a group-based access system. People in the
`packager` group have (commit) access to only the packages they
maintain. People in the `provenpackager` group have (commit) access to
all the active packages, but a few (for legal reason). People in the
`releng` group have commit access to all the packages. Is this an
access model that GitLab can support? If not, how would this work in a
GitLab world? How would notifications work (Esp consider people in the
`provenpackager` or `releng` group do not want to be notified for all
the projects they have access to)?
- Answer: What I explored was something along the lines of :
- Packager → Using GitLab’s Maintainer or Developer role for
the project they maintain (Maintainer have the ability to access
project settings and change pretty much everything there, so that
might be blocking here, Developer only have commit access, so we need
another way to change some settings for Packagers)
- Co-Maintainer → Using GitLab’s Developer role (commit access)
- Proven-Packager → GitLab’s Developer role on all repo (expect 2)
- Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos
- This is not an exact matching with what we currently have
but should give us a way to experiment with this and look at what is
acceptable or not.
- There is also a GitLab ticket
(https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
policies for the project that could give more granular control of
permissions.
- Gitlab’s notifications are quite granular and can be managed
at the different levels (Merge Requests, Projects, Group, Global)
https://docs.gitlab.com/ee/user/profile/notifications.html#global-notific...
- Question: Fedora supports the concept of a retired `project` (ie:
archived) that no-one can commit to. Does GitLab have an equivalent
concept? (The retired status is not something project admins can
change)
- Answer: There is an option to have a “retired” group which is
configured to have nobody with commit access. Then retiring a project
would simply mean to move the project from the “rpm” group to
“retired” group for example.
There is also possibility to simply archive projects
https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project
- Question: could gitlab (inc) maintain a Community Edition GitLab
instance that Fedora uses?
- Answer: There is no plan to create custom versions of GitLab for
customers. Instead, GitLab encourages paid customers and free users
alike to contribute upstream to make sure that GitLab continues to
work well for the most amount of users possible. As an open core
company, GitLab has a public roadmap and works with its community
members to build a great product.
GitLab regularly engages with its community and takes into account its
feedback. As a result, features are often ported down into lower tiers
in order to make the Community Edition and Free tiers continuously
more useful (see example of 18 features moved to open source). GitLab
hosting is available to users of GitLab.com SaaS, but GitLab does not
offer hosting and management for GitLab CE or EE instances.
- Question: Can project creation be restricted to a specific group of
people in GitLab?
- Answer: Yes this can be configured at the instance level
(https://gitlab.com/help/user/admin_area/settings/visibility_and_access_co...)
or at the group level
(https://gitlab.com/help/user/group/index.md#default-project-creation-level)
- Question: Can project (main project, not fork) deletion be
restricted to a specific group of people in GitLab? (ie: project
owner/maintainer must not be allowed to delete a main project, they
can delete their own fork of course)
- Answer: There is an issue
https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help
with this by requiring an additional person approve the deletion &
there’s a related issue
https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list
of authorized approvers for these types of changes (not MRs) that
sounds aligned with this ask
- Question: How would group membership be sync to GitLab?
- Answer: We are still not 100% clear on that, since GitLab
supports OpenIDC & we will need to investigate if we could make use of
the group scope returned by AAA. Otherwise we will need a solution to
sync the groups to GitLab most likely using API calls.
- Question:Will there be better support for Podman in CI workflows in GitLab?
- Answer: Short term solution might be using a custom executor,
long term solution would be getting the Runner executor podman (#4185)
feature request issue scheduled and closed. Ultimately product team
schedules work, while everyone can contribute MRs or fixes ahead of
schedule. In the past, I've seen a lot of enthusiasm from GitLab team
members in helping solve problems from Open Source Program members
whenever possible.
These are all the questions that had answers I could spot from the
larger hackmd document, however my apologies if I missed any.
next week I will pull in all the questions and answers on 'Message
Bus' in a new email and send for discussion.
I know there are still some questions unanswered so I will try to
chase down answers to these, but it could take some time. If I can get
them answered over the next few weeks, I will send a 'misc' topic
email at the end of these few weeks worth of emails.
I hope you find this helpful and it is going to take some time to work
through everything so thank you for your patience and involvement in
this, it is very much appreciated.
Kindest regards,
Aoife
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-announce@lists.fedora...
3 years, 5 months
Fedora 34 Change proposal: Modular GNOME Keyring services
(Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ModularGnomeKeyring
== Summary ==
The monolithic daemon provided by GNOME Keyring will be split into
dedicated sub-daemons, so that they can be consistently managed by
systemd.
== Owner ==
* Name: [[User:ueno|Daiki Ueno]]
* Email: dueno(a)redhat.com
* Name: [[User:benzea|Benjamin Berg]]
* Email: bberg(a)redhat.com
* Product: Workstation
* Responsible WG: Workstation
== Detailed Description ==
GNOME Keyring provides multiple services from a single daemon program
called gnome-keyring-daemon. This daemon is launched by the session
manager (gnome-session) or PAM, depending on desktop environments.
That design makes troubleshooting hard when any issue arises, as well
as the individual services cannot be easily turned off.
Despite its original goal to be the central cryptographic service on
desktop, the scope of GNOME Keyring has been gradually reduced over
years. Notable examples are
[https://bugzilla.gnome.org/show_bug.cgi?id=750514 gpg-agent removal]
in 2015, [https://bugzilla.gnome.org/show_bug.cgi?id=791401 PKCS #11
module deprecation] and
[https://bugzilla.gnome.org/show_bug.cgi?id=775981 ssh-agent rewrite
to wrap ssh-agent from OpenSSH] in 2018. Now that only the essential
services remaining in gnome-keyring-daemon are D-Bus secret-service
and the ssh-agent wrapper, it would be straightforward to split the
daemon into sub-daemons per functionality.
== Benefit to Fedora ==
This will bring in consistent experience of setting up and managing
the individual services provided by GNOME Keyring, taking advantage of
systemd service manager.
== Scope ==
* Proposal owners: gnome-keyring-daemon currently provides 3 services:
D-Bus secret-service, ssh-agent wrapper, and a control socket for PAM
to automatically unlock the login keyring. Those services are either
split out, or removed in favor of other means, in the following steps:
** Make the D-Bus secret-service D-Bus activatable
** Make the ssh-agent wrapper service socket activatable
** Move the ssh-agent wrapper service to gcr
** Modify the PAM module to use libsecret API to unlock the login
keyring, instead of the control socket
** Install systemd unit files for those services, modify the current
session initialization sequence to use them
** (Stretch goal) move the D-Bus secret-service implementation to libsecret
** (Stretch goal) remove the gnome-keyring package from the default compose
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Check if the GNOME Keyring services are now managed by systemd, using
systemctl status. Check if the existing applications (Seahorse, SSH
clients, etc.) still work.
== User Experience ==
No visible change should be observed by normal users.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 5 months
Fedora-Rawhide-20201103.n.0 compose check report
by Fedora compose checker
Missing expected images:
Xfce raw-xz armhfp
Compose PASSES proposed Rawhide gating check!
All required tests passed
Failed openQA tests: 10/181 (x86_64), 16/117 (aarch64)
New failures (same test not failed in Fedora-Rawhide-20201102.n.0):
ID: 715447 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/715447
ID: 715502 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/715502
ID: 715514 Test: aarch64 Server-dvd-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/715514
ID: 715515 Test: aarch64 Server-dvd-iso install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/715515
ID: 715545 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/715545
ID: 715607 Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/715607
ID: 715653 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/715653
Old failures (same test failed in Fedora-Rawhide-20201102.n.0):
ID: 715464 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/715464
ID: 715468 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/715468
ID: 715470 Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/715470
ID: 715507 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/715507
ID: 715530 Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/715530
ID: 715539 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/715539
ID: 715560 Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/715560
ID: 715662 Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/715662
ID: 715665 Test: aarch64 universal install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/715665
ID: 715666 Test: aarch64 universal install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/715666
ID: 715668 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/715668
ID: 715682 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/715682
ID: 715685 Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/715685
ID: 715691 Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/715691
ID: 715692 Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/715692
ID: 715746 Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/715746
ID: 715747 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/715747
ID: 715810 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/715810
ID: 715811 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/715811
Soft failed openQA tests: 3/181 (x86_64), 1/117 (aarch64)
(Tests completed, but using a workaround for a known bug)
New soft failures (same test not soft failed in Fedora-Rawhide-20201102.n.0):
ID: 715445 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/715445
Old soft failures (same test soft failed in Fedora-Rawhide-20201102.n.0):
ID: 715487 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/715487
ID: 715559 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/715559
ID: 715606 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/715606
Passed openQA tests: 168/181 (x86_64), 93/117 (aarch64)
New passes (same test not passed in Fedora-Rawhide-20201102.n.0):
ID: 715411 Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/715411
ID: 715426 Test: x86_64 Server-dvd-iso server_database_client
URL: https://openqa.fedoraproject.org/tests/715426
ID: 715517 Test: aarch64 Server-dvd-iso server_role_deploy_database_server@uefi
URL: https://openqa.fedoraproject.org/tests/715517
ID: 715532 Test: aarch64 Server-dvd-iso server_database_client@uefi
URL: https://openqa.fedoraproject.org/tests/715532
ID: 715661 Test: aarch64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/715661
Skipped non-gating openQA tests: 7 of 298
Installed system changes in test x86_64 Server-boot-iso install_default:
System load changed from 0.05 to 0.21
Previous test data: https://openqa.fedoraproject.org/tests/713417#downloads
Current test data: https://openqa.fedoraproject.org/tests/715393#downloads
Installed system changes in test x86_64 Server-boot-iso install_default@uefi:
System load changed from 0.17 to 0.31
Previous test data: https://openqa.fedoraproject.org/tests/713418#downloads
Current test data: https://openqa.fedoraproject.org/tests/715394#downloads
Installed system changes in test x86_64 Everything-boot-iso install_default:
System load changed from 0.27 to 0.43
Previous test data: https://openqa.fedoraproject.org/tests/713459#downloads
Current test data: https://openqa.fedoraproject.org/tests/715433#downloads
Installed system changes in test x86_64 Workstation-live-iso install_default@uefi:
1 services(s) removed since previous compose: fwupd.service
Previous test data: https://openqa.fedoraproject.org/tests/713462#downloads
Current test data: https://openqa.fedoraproject.org/tests/715438#downloads
Installed system changes in test x86_64 Workstation-live-iso install_default_upload:
Used mem changed from 837 MiB to 967 MiB
Used swap changed from 3 MiB to 6 MiB
1 services(s) added since previous compose: fwupd.service
System load changed from 1.10 to 1.21
Previous test data: https://openqa.fedoraproject.org/tests/713463#downloads
Current test data: https://openqa.fedoraproject.org/tests/715439#downloads
Installed system changes in test x86_64 KDE-live-iso install_default_upload:
Used swap changed from 3 MiB to 7 MiB
Previous test data: https://openqa.fedoraproject.org/tests/713482#downloads
Current test data: https://openqa.fedoraproject.org/tests/715456#downloads
Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload:
Used swap changed from 5 MiB to 6 MiB
Previous test data: https://openqa.fedoraproject.org/tests/713499#downloads
Current test data: https://openqa.fedoraproject.org/tests/715474#downloads
Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi:
System load changed from 1.28 to 1.44
Previous test data: https://openqa.fedoraproject.org/tests/713498#downloads
Current test data: https://openqa.fedoraproject.org/tests/715478#downloads
Installed system changes in test aarch64 Server-dvd-iso install_default_upload@uefi:
System load changed from 0.68 to 0.36
Previous test data: https://openqa.fedoraproject.org/tests/713533#downloads
Current test data: https://openqa.fedoraproject.org/tests/715504#downloads
Installed system changes in test x86_64 universal install_package_set_kde:
Used mem changed from 985 MiB to 1086 MiB
System load changed from 0.83 to 0.94
Average CPU usage changed from 1.55714286 to 26.44761905
Previous test data: https://openqa.fedoraproject.org/tests/713587#downloads
Current test data: https://openqa.fedoraproject.org/tests/715562#downloads
Installed system changes in test aarch64 universal install_package_set_minimal@uefi:
26 packages(s) added since previous compose: gdisk, libatasmart, libblockdev, libblockdev-crypto, libblockdev-fs, libblockdev-loop, libblockdev-mdraid, libblockdev-part, libblockdev-swap, libblockdev-utils...
1 services(s) added since previous compose: polkit.service
System load changed from 0.29 to 0.41
Previous test data: https://openqa.fedoraproject.org/tests/713684#downloads
Current test data: https://openqa.fedoraproject.org/tests/715686#downloads
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
3 years, 5 months
