- Pagure-devel - Fedora mailing-lists

how to delete user and groups in pagure
by zhang wenlong 02 Nov '21

02 Nov '21

Hello, I am using pagure, but I cannot delete users and groups, nor can I find the corresponding interface or command. How can I delete the corresponding information?

1 0

How to set git storage warehouse permissions
by zhang wenlong 02 Nov '21

02 Nov '21

i modify the Folder containing to the git repos in /etc/pagure/pagure.cfg just like GIT_FOLDER = os.path.join( '/srv/git', 'repos' ) and “/srv/git” is the home of user git, When I open the pagure page, there is always the following prompt “The permissions on this repository are being updated. This may take a while. During this time, you or some of the project's contributors may not be able to push to this repository” and i can't delete project at the same time What should I set the permissions to /srv/git

1 0

[Release] Pagure 5.13.2
by Neal Gompa 20 Mar '21

20 Mar '21

Good morning all, Unfortunately, we've been remiss in announcing Pagure releases for the past few ones, including Pagure 5.13.2 released last month! Sorry about that, we'll try to announce these properly in the future. Here's the full changelog: 5.13.2 (2021-01-29) ------------------- - Fix broken pagination of group API (Lukas Brabec and František Zatloukal) - Fixing the alias url in the examples (Mohan Boddu) - Pull in upstream fix for apostrophes from highlightjs-rpm-specfile (David Auer) - Improve logging when trying to interract with a git repo via http(s) 5.13.1 (2021-01-29) ------------------- - Add the api_project_hascommit endpoint to the API doc - Do not return a 500 error when the OpenID provider doesn't provide an email - Fix bug in the default hook 5.13.0 (2021-01-19) ------------------- - When failing to find a git repo, log where pagure looked - Get the default branch of the target repo when linking for new PR - Add an hascommit API endpoint - Fixing sample input and output for alias related api (Mohan Boddu) - Add missing API endpoints related to git aliases and re-order a little - Add support for chardet 4.0+ - Fix support for cchardet 5.12.1 (2021-01-08) ------------------- - Block chardet 4.0, we're not compatible with it yet - Be consistent in the messages sent and with the schemas defined in pagure-schemas (0.0.4+) - Make the token_id column of the commit_flags table nullable 5.12.0 (2021-01-06) ------------------- /!\ The PR flag API now creates Commit flags on the commit at the top of the pull-request. - Display real line numbers on pull request's diff view (Julen Landa Alustiza) - Show the assignee's avatar on the board - Allow setting a status as closing even if the project has no close_status - Include the assignee in the list of people notified on a ticket/PR - Add orphaning reason on the dist-git theme (Michal Konečný) - Adjust the way we generate humanized dates so we provide the humanized date as well as the actual date when hovering over (Julen Landa Alustiza) - When a file a detected as a binary file, return the raw file - Allow using the modifyacl API endpoint to remove groups from a project - Add a note that repo_from* argument are mandatory in some situations when opening a Pull-Request from the API - Increase the list of running pagure instances in the documentation (Neal Gompa) - Remove fenced code block when checking mention (Michael Scherer) - Add support for using cchardet to detect files' encoding - Show the default branch in the project overview page - Send appropriate SMTP status codes and error messages in the milter. (Björn Persson) - Report an error if a message ID isn't recognized by the milter. (Björn Persson) - Add support for disabling user registration (Neal Gompa) - Add a way to make the stats view on more than one year (if you know how to) - Encode the data passed onto the mail hook so it is of bytes type - Reverse out of order instructions for new repos (Jerry James) - Split the list of branches into two lists active/inactive in dist-git - Rework the "My PR" page so it does not pull so many info at once - Include the date of the last mirroring process in the logs - Forward the username when updating the pull-request - Add pagination to group API (Michal Konečný) - When returning the commits flags in the API, returned them by update date - Change the PR flag API endpoints to use commit flags - Only show the subscribers list on demand - Improve the message showns when a new mirrored project is created - When editing the issue's description sent the html of it to the SSE server - Add an update-acls action to pagure-admin - Add support for AAA system sending SSH keys encoded in base64 - Allow deleting the master branch when it is not the default branch - Allow people with a fork to have a working drop-down for opening new PRs - Fix handling "false" when editing project's options via the API (Bernhard M. Wiedemann) - Ensure a fork project has the same default branch as its parent - Allow to specify a default branch for all projects hosted on an instance - Add support for pagure-messages - Add a notification for when a group is removed from a project - When checking if messages were sent via a rebase, do not run the git hooks - Make the API endpoint to update project's options accept JSON - Add a full_url to the JSON representation of our main objects - Ensure the author in git commit notifications follow the expected format - Add support for git branch aliases - Update the vagrant development environment - Allow updating the target branch when editing a PR 5.11.3 (2020-08-11) ------------------- - Fix installability of web-apache-httpd subpackage on EL7 (Neal Gompa) - Fix the model around the boards so it works with mariadb/mysql - Add new endpoints to the API documentation 5.11.2 (2020-08-04) ------------------- - Allow having a dedicated logging configuration for the git hooks 5.11.1 (2020-08-03) ------------------- - Increase logging to the pagure_auth logger - Make work pagure-admin ensure-project-hooks when the target link exists but is broken - Fix sorting collaborators and groups of collaborators - Fix git push over http(s) 5.11.0 (2020-08-03) ------------------- - Change the project icon when the project is mirrored from an external source - Allow a theme or a blueprint to inject custom buttons in the navigation bar. (zPlus) - Add API endpoint to get a pull-request comment (Lukas Holecek) - Omit breaking original comment format in reply on pull-requests (Lukas Holecek) - Let the milter announce when it reject an email based on its address - Don't Let the milter process the email we send. (Björn Persson) - Add a collaborator level to projects - Allow collaborators to edit files in the branch that they have access to - Add orphan button to project page (Michal Konečný) - Allow setting the default git branch when creating projects via the API - Allow creating mirrored project from the API - Add the possibility to set the default branch at project creation - Add API endpoint to set the default git branch and expose it in an existing endpoint - Adjust the example configuration for logging to a file - Allow project-less API token with the "modify_project" ACL to update watchers - spec: Have the log directory owned by the main package (Neal Gompa) - Add a new API endpoint to retrieve a commit's metadata/info - Add a new API endpoint allowing to delete a project - Add support for customizing the new issue page - Introducing the boards feature - Add an API endpoint to view the content of a git repo - Port pagure's markdown extension to the new API - Multiple small fixes for the vagrant-based development environment - Use WhiteNoise to serve static assets for the Pagure web - Fix running the tests on py 3.8 - Port pagure's test suite to pytest - Fix the title of the graph showing the evolution of the number of open tickets on a project - Do not assume there is a SMTP_STARTTLS configuration key set - Bring back JS library used for the heatmap (Nils Philippsen) - Show the ACL name in addition to the description when creating API tokens - Allow editing the URL a project is mirrored from - Add comments to the mirror service files for clarifying their purpose. (zPlus) - Fix warning when compiling the doc - Add a dedicated logger for everything that is auth related - api: fix apidoc format on api_view_issues_history_detailed_stats Fixes web api doc view template issues (Julen Landa Alustiza) - doc: Add a page documenting known Pagure instances (Neal Gompa) - starttls support via SMTP_STARTTLS: provide additional documentation. (midipix) - Add support for smtp server requiring starttls to work - Make the stats page use the new stats API endpoint And as always, I'd like to thank our contributors for these past few releases! $ git shortlog -s -n 5.10.0..5.13.2 153 Pierre-Yves Chibon 9 Björn Persson 8 Neal Gompa 5 Julen Landa Alustiza 5 Lukas Holecek 4 Michal Konečný 2 Andrew Engelbrecht 2 Aurélien Bompard 2 Bernhard M. Wiedemann 2 František Zatloukal 2 Michael Scherer 2 Mohan Boddu 2 siddharthvipul 2 zPlus 1 David Auer 1 Jerry James 1 Koichi MATSUMOTO 1 Lubomír Sedlář 1 Lukas Brabec 1 Nils Philippsen 1 Sergio Durigan Junior 1 midipix With this release, we welcome several new contributors: Björn Persson, Lukas Holecek, Bernhard M. Wiedemann, František Zatloukal, David Auer, Jerry James, Koichi MATSUMOTO, Lukas Brabec, Nils Philippsen, and midipix! Thank you all for your efforts and we hope you continue to enjoy using and hacking on Pagure! Finally, Pagure 5.13.2 sources are available at the usual place: https://pagure.io/pagure/releases As for packages, Pagure 5.13.2 is available now in Fedora 32 and up; CentOS/RHEL 7 and 8 via EPEL; openSUSE Leap 15.3; openSUSE Tumbleweed; and Mageia 8. Other distributions shipping Pagure have their own timelines on releasing updates, please check with them for further information. :) Best regards, Neal Gompa -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

Generalized concept of "data"/pagination in Pagure API?
by Tim Landscheidt 26 Feb '21

26 Feb '21

Hi, I'd like to interact with Pagure from within Emacs (Lisp) and therefore am adding support to Ghub (https://github.com/magit/ghub/) Ghub has a nice unpagination feature that automatically col- lects all queried data in consecutive requests and builds one structure from that. For GitHub and some other forges, this is easy: For example https://api.github.com/orgs/microsoft/repos returns a JSON array and has an HTTP header "link" (RFC 8288) that refers to the next (and the last) page, so a program can mindlessly request each page, concatenate the arrays, et voilà! Looking at Pagure's API, there does not seem to exist such an overarching idea. Therefore (?), the "pagure" command line utility (https://github.com/juhp/pagure-cli) has a sep- arate Haskell command for each API call, and the "libpagure" Python library (https://pagure.io/libpagure/) does the same. Is there a way that a Pagure API client library can be "clever" with regard to pagination at a low level and pre- sent the consumer with a DWIM data structure? (My most-head-scratching problem is https://src.fedoraproject.org/api/0/user/scfc where there are two dimensions of pagination, and keys ("forks", "repos") whose values should be concatenated and another key ("user") whose values should not be.) TIA, Tim

2 1

Pagure Considerations within the CPE GitForge Decision
by Aoife Moloney 18 May '20

18 May '20

Hi Pagure Community, During a recent office hours on IRC, I was asked, actually reminded, that the analysis of Pagure had yet to be sent. My apologies for this and thank you Defolos for the reminder :) and for holding me accountable! The below text was lifted from an internal google document used by CPE management and above, when discussing what gitforge option to pursue, and copied to this hackmd file for convenience for readers who are using terminals, etc to consume. I hope this email serves an information sharing purpose and even possibly a roadmap of sorts of improvements that I have no doubt are either being actively worked on or could be developed in Pagure, and I look forward to the good conversations this may generate. # GitForge Decision Considerations Recently, the Community Platform Engineering (CPE) team who look after both the Fedora and CentOS Communities ran an analysis on what their future Gitforge needs would look like. As part of that, we analysed Pagure and in our follow on discussions we promised to feed back into the Pagure community the gaps as we saw them which played a part in our decision making process. The text below can be ported to various issues, just let us know the most appropriate location and we are happy to offer our assistance in fleshing these out. Please note that this is a requirements driven view of the capabilities of Pagure and is not a slight at the work the community and indeed the CPE team have put into this project over the years. We deeply appreciate the efforts of all contributors and we hope that this mail is insightful and helps to build a strong Pagure. ## Technical Recommendations: A number of technical requirements that Pagure would need to consider to meet some of our requirements are as follows: ### Additional Single Sign On (SSO) Integration The CPE team work closely with the RHEL, CentOS and Fedora projects and the ability to have a workflow within the gitforge means a need for SSO integration with those systems is a key need. ### Reliability & Performance Some projects that host Pagure and wish to operate on a high uptime backed by a Service Level Agreement (SLA) -- where uptime is measured in the 99.9% bracket -- are unable to do so without additional considerations already present within the Pagure project. Currently all CPE can offer are general Service Level Expectations (SLE). To enable an SLA, it’s partly additional resourcing to help ensure uptime but a huge investment is required in API monitoring to spot a problem and try and resolve it prior to an issue taking the service off the air. Pagure needs extensive work on API monitoring to improve the ability to transition this from an towards a viable SLA model. Right now there are 6 Nagios checks running on Pagure which the CPE team have created. SLA levels are in the thousands of Nagios Checks (>10k in many cases) to help us understand where improvements need to go and what is causing issues. Pagure is resource heavy and numerous tickets have noted the sluggishness of Pagure (multiple reported issues on PR creation and searching). To solve issues like this, we need observability and even then the route fix might be re architecture of core components to leverage more redundancy and create a means for resiliency whereby individual failures will not take down the entire service. That deep level of architectural analysis would be highly recommended and if CPE can help we are more than happy to offer our expertise. ### Team Collaboration Features Pagure is lacking several key features in team collaboration: inline images in PRs a full suite of PR comments [1] features to allow richer reviews on PRs the ability to collaborate on project planning capabilities (Kanban boards) including linking of issues through to PRs. The ability to infer stats from your codebase and insights for improvements. The ability to migrate issues easily between projects. The ability to rename or move projects between namespaces. The ability to edit tags[1,2] on issues and the ability to cleanup forks through the API. The ability to allow for a better granularity of which events are sent on the webhook to facilitate integration with other applications collaboration of apps through webhooks. While a webhook functionality exists, this is all or nothing approach, whereby every event triggers the hook or none do. In short, the day to day working of a team and collaboration within a project is right now not optimal ### Accessibility and User Interface(UI)/User Experience (UX): Pagure has multiple accessibility compliance issues. While some of these issues are easy fixes, many obvious issues relate to style and theming. The overall UX has a number of issues which need a modern refresh to make the system more amenable to new users of a Git Forge or those familiar with other forge UIs who might struggle with concepts like merging and conflicts [1,2]. Discovery of projects or issues is difficult [3] which hampers attempts at drive by contributors to discover and partake. Attracting and lowering the barrier for new users and particularly those who do not have a strong background in the usage of git was a focal point of several requirements. ### Workflow Integrations Pagure has integrations with other standalone services to help facilitate workflow integrations and general Continuous Integration (CI)/ Continuous Deployment (CD) capabilities. While the integrations are positive, it blooms the scope of responsibility, as addressing Pagure means by extension addressing the individual components that help to plug feature gaps within Pagure. This extends our SLA coverage by an order of magnitude. Additional considerations here are the all or nothing nature of the webhooks which makes integrations with other tooling more problematic (e.g. automatic build triggers) Take care everyone and have a lovely weekend, Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

3 2

Query on extending the commit list view?
by Neal Gompa 19 Apr '20

19 Apr '20

Hello, One of the things I like about Pagure is that the commit list view shows you the branch and tag refs associated with commits, even those from not in your branch. For example, the pagure package Git repo shows the top commit in master also in other Fedora and EPEL branches too[1]. What I was wondering is how easy it would be to extend this to also look for other refs, enumerate them, and create links. The main use-case would be when Gerrit is paired with Pagure. Gerrit stores changes as refs in the repo in the refs/changes namespace. The formula of the changes ref mapping to a Gerrit change review is as follows: refs/changes/56/123456/7 -> https://<hostname>/#/c/123456/7 What I'd like to do is make it so those show up in the commit view as blue refs (blue being Gerrit's color on the website) that when you click them, you are taken to Gerrit to see the change review page. I think this extension would make sense as a plugin rather than being part of the core, but I could go either way on that... I understand that doing this is potentially a lot more expensive, since now Pagure would have to *read* all these refs, but the use-case is interesting. :) Ideally, this would be paired with the RFE for linking Change-Ids[2]. [1]: https://src.fedoraproject.org/rpms/pagure/commits/master [2]: https://pagure.io/pagure/issue/4812 -- 真実はいつも一つ！/ Always, there's only one truth!

2 1

Thoughts for Pagure 6.0
by Neal Gompa 26 Jan '20

26 Jan '20

Hey all, So we're in the throes of developing what will become Pagure 5.9, but I'd like to take a moment to talk about Pagure 6.0. As an upcoming major version bump, this is an opportunity to make some world-breaking changes that would be better for users of Pagure. Here are some thoughts I have about what we should do for Pagure 6.0: * Drop Python 2 support and raise the minimum version of Python to 3.6. Most of our dependencies have dropped Python 2 support with the EOL on January 1. This includes Flask and related components[1]. * Along with the Python 2 support being dropped, switch all code using trololio to use asyncio. We're only using trololio because we need a consistent wrapper between now-dead Trollius for Python 2 and asyncio for Python 3. * Stop using the Gitolite backend by default, and use the built-in "pagure" backend instead. This backend has been in use on pagure.io for a while now and seems to work reasonably well. We may want to consider ripping out Gitolite support, but I think that *might* be a bit premature. * Consider changing from our default recommended production setup with mod_wsgi and apache httpd if we can identify a more performant alternative setup. This may also help with making Pagure more "cloud-native" (i.e. k8s-friendly) by default, too. Which leads to... * Make an officially supported OpenShift and Kubernetes deployment strategy. We've had a PR open for the better part of the year for adding Helm charts[2], but there's still some base work that needs to be done for officially supporting a containerized deployment option. Do we also want to have an operator and list on OperatorHub.io? All of these are just ideas/suggestions. We don't have to do any or all of these things, but these are some of the things I think might be good for Pagure 6.0. Feedback on these ideas are welcome, as well as your own ideas or suggestions! So, what do you all think? Any of these good? Any better ideas? Or am I completely off-base here? [1]: https://www.palletsprojects.com/blog/ending-python2-support/ [2]: https://pagure.io/pagure/pull-request/4483 -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

How do you audit your repos for spam or abuse?
by Andrew Engelbrecht 07 Jan '20

07 Jan '20

Hello Pagure devel list, Sorry if this isn't quite the right place for this question. The FSF is looking into hosting our own Web based SCM service, possibly using Pagure. We would like to how the pagure.io team handles spam, abuse, and overly large repos on your site. We expect that this could be an issue, and that it would be critical for keeping our new site alive and well. Any input on this topic would be very helpful. Thanks, : ) Andrew

4 5

Fwd: [Pagure] Pagure API key expiration date is near!
by Miro Hrončok 16 Aug '19

16 Aug '19

Hey! I just got this e-mail. Consider this an RFE to tell me where to renew the token. For Fedora purposes, it would also be nice if it told me where to put it to continue packaging smoothly. Thanks, Your Pagure User. PS, if you reply, please make sure I stay in the recipients. -------- Forwarded Message -------- Subject: [Pagure] Pagure API key expiration date is near! Date: Fri, 16 Aug 2019 00:00:10 +0000 (UTC) From: pagure(a)pagure.io To: mhroncok(a)redhat.com Hi Miro Hrončok, Your Pagure API key fedpkg.pagure will expire in 5 day(s). Please get a new key for non-interrupted service. Thanks, Your Pagure Admin.

2 1

Skipping the June release
by Pierre-Yves Chibon 04 Jun '19

04 Jun '19

Good Morning Everyone, We have just released pagure 5.6 which was due in early May. Due to this late release of 5.6, I propose that we skip the release of June 7th and target 5.7 on July 7th. Happy hacking! Pierre

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

Pagure-devel