About JS framework
by Pierre-Yves Chibon
Good Morning Everyone,
Our infrastructure is mostly a python store, meaning almost all our apps are
written in python and most using wsgi.
However in python we are using a number of framework:
* flask for most
* pyramid for some of the biggest (bodhi, FAS3)
* Django (askbot, Hyperkitty)
* TurboGears2 (fedora-packages)
* aiohttp (python3, async app: mdapi)
While this makes sometime things difficult, these are fairly standard framework
and most of our developers are able to help on all.
However, as I see us starting to look at JS for some of our apps (fedora-hubs,
wartaa...), I wonder if we could start the discussion early about the different
framework and eventually see if we can unify around one.
This would also allow those of us not familiar with any JS framework to look at
the recommended one instead of picking one up semi-randomly.
So has anyone experience with one or more JS framework? Do you have one that
would you recommend? Why?
Thanks for your inputs,
Pierre
1 year, 5 months
Fedora 27 Beta Freeze now in effect
by Kevin Fenzi
Greetings.
we are now in the infrastructure freeze leading up to the Fedora 27 Beta
release. This is a pre-release freeze.
We do this to ensure that our infrastructure is stable and ready to
release the Fedora 27 Beta when it's available.
You can see a list of hosts that do not freeze by checking out the
ansible repo and running the freezelist script:
git clone
https://infrastructure.fedoraproject.org/infra/ansible.git
ansible/scripts/freezelist -i inventory
Any hosts listed as freezes is frozen until 2017-09-19 (or later if Beta
slips). Frozen hosts should have no changes made to them without a
sign-off on the change from at least 2 sysadmin-main or rel-eng members,
along with (in most cases) a patch of the exact change to be made to
this list.
Thanks,
kevin
5 years, 11 months
FBR: 🎶if you liked it then you should've put a lock on it...🎶
by Ralph Bean
... or even if you didn't like it, it still probably needs a lock.
/usr/local/bin/pagure-sync-bugzilla.py takes more than 24 hours to
run, and it doesn't have a lock wrapper on it. It needs one.
diff --git a/roles/distgit/pagure/tasks/main.yml b/roles/distgit/pagure/tasks/main.yml
index 8cdf0b3..9079f06 100644
--- a/roles/distgit/pagure/tasks/main.yml
+++ b/roles/distgit/pagure/tasks/main.yml
@@ -228,7 +228,7 @@
user: root
minute: 0
hour: 18
- job: /usr/local/bin/pagure-sync-bugzilla.py
+ job: /usr/bin/lock-wrapper pagure-sync-bugzilla "/usr/local/bin/pagure-sync-bugzilla.py"
cron_file: pagure-sync-bugzilla
state: present
when: env != 'staging'
Anyone for it? Against it?
6 years, 5 months
Deploying new version of Elections app?
by Justin W. Flory
Hi all,
I had a brief conversation with Pingou a few weeks ago during the
elections about deploying a new version of the Elections app with some
of the UI/UX rework that Ryan Lerch worked on last year.
The current codebase can be found here:
https://pagure.io/elections
Is there a way the current version could be put into a staging instance?
Thanks!
--
Cheers,
Justin W. Flory
jflory7(a)gmail.com
6 years, 5 months
Retroactive compose FBR
by Dennis Gilmore
I have updated pungi on compose-x86-01 compose-x86-02 and branched-
composer to 4.1.19
the full transaction on all boxes was
[root@branched-composer ~][PROD]# yum --enablerepo updates-testing
update pungi
Fedora 26 - x86_64 - Test
Updates
58 MB/s | 2.6 MB 00:00
Last metadata expiration check: 0:00:00 ago on Sat 30 Sep 2017 05:35:47
PM UTC.
Dependencies resolved.
=======================================================================
=======================================================================
==========================================================
Package Arch
Version
Repository Size
=======================================================================
=======================================================================
==========================================================
Upgrading:
kobo noarch
0.6.0-
1.fc26 updates
108 k
kobo-
rpmlib noarch
0.6.0-
1.fc26 updates
32 k
pungi noarch
4.1.19-
1.fc26 updates-
testing 778 k
pungi-
utils noarch
4.1.19-
1.fc26 updates-
testing 72 k
Transaction Summary
=======================================================================
=======================================================================
==========================================================
Upgrade 4 Packages
Total download size: 989 k
Is this ok [y/N]: y
Downloading Packages:
(1/4): kobo-rpmlib-0.5.2-3.fc26_0.6.0-
1.fc26.noarch.drpm
3.3 MB/s
| 22 kB 00:00
(2/4): kobo-0.5.2-3.fc26_0.6.0-
1.fc26.noarch.drpm
2.3
MB/s | 35 kB 00:00
(3/4): pungi-utils-4.1.19-
1.fc26.noarch.rpm
9.5 MB/s | 72 kB 00:00
(4/4): pungi-4.1.19-
1.fc26.noarch.rpm
24 MB/s | 778 kB 00:00
[DRPM 1/2] kobo-rpmlib-0.5.2-3.fc26_0.6.0-1.fc26.noarch.drpm:
done
[DRPM 2/2] kobo-0.5.2-3.fc26_0.6.0-1.fc26.noarch.drpm:
done
---------------------------------------------------------------------
---------------------------------------------------------------------
--------------------------------------------------------------
Total
5.2 MB/s | 907 kB 00:00
Delta RPMs reduced 1.0 MB of updates to 0.9 MB (8.1% saved)
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing :
1/1
Upgrading : kobo-0.6.0-
1.fc26.noarch
1/8
Upgrading : kobo-rpmlib-0.6.0-
1.fc26.noarch
2/8
Upgrading : pungi-4.1.19-
1.fc26.noarch
3/8
Upgrading : pungi-utils-4.1.19-
1.fc26.noarch
4/8
Cleanup : pungi-utils-4.1.17-
2.fc26.noarch
5/8
Cleanup : pungi-4.1.17-
2.fc26.noarch
6/8
Cleanup : kobo-rpmlib-0.5.2-
3.fc26.noarch
7/8
Cleanup : kobo-0.5.2-
3.fc26.noarch
8/8
Verifying : pungi-4.1.19-
1.fc26.noarch
1/8
Verifying : kobo-0.6.0-
1.fc26.noarch
2/8
Verifying : pungi-utils-4.1.19-
1.fc26.noarch
3/8
Verifying : kobo-rpmlib-0.6.0-
1.fc26.noarch
4/8
Verifying : pungi-4.1.17-
2.fc26.noarch
5/8
Verifying : kobo-0.5.2-
3.fc26.noarch
6/8
Verifying : kobo-rpmlib-0.5.2-
3.fc26.noarch
7/8
Verifying : pungi-utils-4.1.17-
2.fc26.noarch
8/8
Upgraded:
kobo.noarch 0.6.0-1.fc26 kobo-rpmlib.noarch
0.6.0-1.fc26 pungi.noarch 4.1.19-
1.fc26 pungi-utils.noarch 4.1.19-
1.fc26
Complete!
We can downgrade if they have problems. The reason I went and updated
pungi was to pull in the patch https://pagure.io/pungi/c/fcbc3ed4aeeab8
1056fc5b18d4c4f4445009d915?branch=master which has caused some pretty
big issues with Beta.
Dennis
6 years, 5 months
Proposal: updated pyOpenSSL in the epel7-infra repository
by Jeremy Cline
Hey folks,
I'd like to propose that we build a newer version of pyOpenSSL for EL7.
The version provided by base RHEL is 0.13.1. We need at least 16.1.0.
The motivation for this proposal is that at the moment, fedmsg has two
implementations of message signing and verification. The first is based
on M2Crypto and m2ext, while the second is based on cryptography and
pyOpenSSL.
The reason there are two implementations is that M2Crypto does not
support Python 3. Python 2 reaches end of life in 30 months. fedmsg is a
dependency of nearly every Infrastructure application and thus it
supporting Python 3 is critical so that we can start the process of
supporting Python 3 in our applications.
In order to provide a Python 3 build of fedmsg for EL7, we need to build
a newer pyOpenSSL. I reviewed the changelogs[0][1] and from what I can
tell APIs were only extended until pyOpenSSL-17.1.0, at which point
several backwards-incompatible changes were made. I believe we could
safely update to 17.0.0 without breaking applications that depend on it.
I've made a small list of pros and cons to doing this:
Cons
----
* Building a package provided by RHEL's base repository.
* Some risk of breaking applications and libraries using pyOpenSSL.
* We have to maintain it and keep an eye open for any CVEs.
* Even if we do this, fedmsg has to continue to carry the M2Crypto
code unless we want to stop updating fedmsg in EPEL (I'm open to
this, but I'm biased - I really don't want to maintain M2Crypto code).
Pros
----
* Applications have an easier time porting to Python 3. New applications
can seriously consider being Python 3 only.
* A single code path for signing and validating messages for our
applications.
What do people think? Is it worth the headache/risk?
[0] https://github.com/pyca/pyopenssl/blob/master/doc/ChangeLog_old.txt#L188
[1] https://pyopenssl.org/en/stable/changelog.html
--
Jeremy Cline
XMPP: jeremy(a)jcline.org
IRC: jcline
6 years, 5 months
[Release] pagure-dist-git: 0.7
by Pierre-Yves Chibon
Good Morning Everyone,
Earlier today I cut a new release of pagure-dist-git: 0.7.
Here is its changelog:
* Fri Sep 29 2017 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 0.7-1
- Update to 0.7
- Fix provenpackager access, they also need branch access
- Add support for the custom username in the SSH URL
- Remove caching when querying PDC so that Gitolite ACLs are not generated
with stale data (Matt Prahl)
- Warn the committers if PRs are turned off and there is no readme
- Add a small script dumping the main admins of each project in pagure
It's deployed in stg and so far works fine :)
The output of the cron job referred to in the last line of the changelog can
be found in:
https://src.stg.fedoraproject.org/extras/
Happy packaging,
Pierre
6 years, 5 months
[FBR] Hotfix pagure on src.fp.o
by Pierre-Yves Chibon
Good Morning Everyone,
In order to fix https://pagure.io/releng/fedora-scm-requests/issue/1078 I would
like to manually apply the following change to pagure on src.fp.o:
--- a/pagure/forms.py
+++ b/pagure/forms.py
@@ -31,7 +31,7 @@ import pagure.lib
STRICT_REGEX = '^[a-zA-Z0-9-_]+$'
TAGS_REGEX = '^[a-zA-Z0-9-_, .]+$'
-PROJECT_NAME_REGEX = '^[a-zA-z0-9_][a-zA-Z0-9-_]*$'
+PROJECT_NAME_REGEX = '^[a-zA-z0-9_][a-zA-Z0-9-_\.]*$'
FALSE_VALUES = ('false', '', False, 'False', 0, '0')
I'll try to find a more elegant/flexible solution for the long term in pagure
itself (like a configuration key).
+1s?
Thanks,
Pierre
6 years, 5 months
[Release] pagure: 3.8
by Pierre-Yves Chibon
Good Morning Everyone,
I just cut a new release of pagure: 3.8.
Here is its changelog:
* Fri Sep 29 2017 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 3.8-1
- Update to 3.8
- Fix API documentation for git/branch (Matt Prahl)
- Fix giving a project to someone who already has access (Matth Prahl)
- Add some border to the tables created in README files
- Ask the user to confirm merging a pull-request
- Fix processing status and close_status updates in the SSE
- Fix the URL to the issue used by the SSE JS on tags
- Increase the logging in the milter to help figuring out issues in the future
- Fix the In-Reply-To header when sending notifications
- Fix showing the delete project button
- Fix search issues with a unicode character
- Catch exception raised when accessing the head of the repo
- Fix deleting a project when some of the folder are not used
- Allow viewing a PR when its origin (fork or branch) is gone
- Fix linking to issue or PR in namespaced projects via #<id>
- Make it more obvious that the namespace and the project are different links
- Tell fedmsg to send things with pagure certificates (Patrick Uiterwijk)
- Fix loading ticket templates on namespaced project and extracting their names
- Add a banner on the overview page when the ACLs are being refreshed on the
backend (and thus ssh access may not be entirely functional) (Vivek Anand)
- Update the documentation on how to create pull requests (Clement Verna)
- Add button to refresh external pull requests (Patrick Uiterwijk)
- Add the possibility to get the group members when asking the project info
- Make the PROJECT_NAME_REGEX used in form be configurable
- Adjust the milter to support replying with any email addresses associated
- Allow pagure admin to give a project
Working to updating stg.pagure.io and src.stg.fp.o to it.
Happy hacking!
Pierre
6 years, 5 months
PDC release data (for F28)
by Paul W. Frields
Hi, I met up with abompard and Kellin today to solidify a plan to deal
with this issue affecting Fedora:
<https://github.com/product-definition-center/product-definition-center/is...>
Here are the notes from the session. It looks like Django makes this
reasonably easy to solve via extending the app. Andrew, the guy
mentioned below, is one of the PDC owners inside Red Hat. I don't
think he's involved in Fedora, which is not an issue; the point is
to keep in touch with him to validate our approach.
* * *
PDC enhancements -- 2017-09-29
Attendees: pfrields, rmarshall, abompard
https://github.com/product-definition-center/product-definition-center/is...
https://github.com/product-definition-center/product-definition-center/is...
* What did Rob discover about PDC approach?
* Talked with Andrew, so if we have an app with an API endpoint we can hit with our dataset, that should work well. We can extend the data model the way that we need it.
* Rob's stuff he was looking at was about builder and architecture type, not really related to these issues.
* What can/should Aurélien contribute?
* Looked at PDC source code -- can write the resource containing the necessary models and hooking up an API endpoint
* Should keep in touch with Andrew to get the patch in
* AGREED: abompard will take this work up... target is to get this in so we can use for F28
* Dates can change over time
* E.g. release date slips or the EOL date is changed
* rob: If we can keep a "changelog" of slip dates, that might be helpful. Not sure how to handle this in the API but it would be great if the data model could accommodate somehow.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
6 years, 5 months