Hello,
Matt and I are releasing a new version of Greenwave and WaiverDB for
Fedora. We are starting in these moments.
We are available on IRC.
Cheers
Giulia
Dear all,
You are kindly invited to the meeting:
Infra Office Hours on 2019-01-15 from 18:00:00 to 19:00:00 UTC
At fedora-admin(a)irc.freenode.net
The meeting will be about:
Weekly hour dedicated to answer questions or help people with fixing tickets or implementing features.
Source: https://apps.fedoraproject.org/calendar/meeting/9255/
Hi everyone,
right now I'm trying to deploy version 0.14.0 of Anitya on
release-monitoring.org.
Unfortunately there is a creation of new index in database, which is
taking longer than expected.
So right now release-monitoring.org is unavailable. I will let you know
when it will be available again.
Regards,
mkonecny
Hello,
When I try to access a few fedora related resources from my university
network, I tend to get certificate errors. I was getting these from
fedoramagazine.org, then from meetbot, and I got one when running
`fedpkg build` that really freaked me out:
$ fedpkg build
Could not execute build: The connection to PDC failed while trying to get the active release branches. The error was: HTTPSConnectionPool(host='pdc.fedoraproject.org', port=443): Max retries exceeded with url: /rest_api/v1/component-branches/?global_component=lifeograph&fields=name&fields=active (Caused by SSLError(SSLCertVerificationError("hostname 'pdc.fedoraproject.org' doesn't match either of 'phishing-alert.herts.ac.uk', 'www.phishing-alert.herts.ac.uk', 'f5-phishing-alert.herts.ac.uk'")))
I tried it again, and it worked (phew!), but I haven't been able to get
fedoramagazine to work at all.
I've filed a ticket with university IT already. Their initial comment
was: "site is report (sic) to be using an invalid certificate. It is not
blocked manually by UH", which is probably inaccurate given that we have
no issues with these web resources outside the university network.
Would anyone have any hints on what they may be doing? I know it's a
hard problem to diagnose without knowing what the university IT is upto,
but any hints that I could pass on to them would be appreciated.
--
Thanks,
Regards,
Ankur Sinha "FranciscoD"
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
Currently, the content for a Flatpak in Fedora can be found in
modules/<application>. E.g.:
https://src.fedoraproject.org/modules/quadrapassel/tree/master - I’d
like to propose creating a separate namespace in src.fedoraproject.org
- flatpaks/
Benefits:
* Allow automation to easily distinguish Flatpaks from other modules.
(https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
)
* Make it easy to browse through the source of available Flatpaks
* Reduce some confusion. A Flatpak is a module, but it’s *also* a
container, and the dist-git repository will include files for both.
Downsides:
* We have a few graphical applications that are available as standard
loose-rpm macros (gimp, rawtherapee, skychart). While it should work
to have flatpaks/gimp and modules/gimp build different streams of the
gimp module, it’s going to be more confusing than different branches
in the same repository. (There are even possibilities for using the
*same* branch using module-stream-expansion, though that’s not
something I’d encourage at the moment.)
Needed steps:
* Remove special casing of flatpak => modules in Bodhi
https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/models.py#L…
* Adjust namespace special-casing in fedpkg
https://pagure.io/fedpkg/blob/master/f/fedpkg/cli.py
* Adjust namespace special-casing in fedscm_admin
https://pagure.io/fedscm-admin/blob/master/f/fedscm_admin/utils.py
* In fedscm_admin: Map flatpaks namespace to the ‘module’ PDC branch
type when storing the SLA into the PDC, to avoid PDC changes, and
because the SLA really is a module SLA.
* Adjust distgit pagure configuration to add flatpaks to
ALLOWED_PREFIX and REQUIRED_GROUPS
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/distgi…
* Add flatpaks/ to the kojid allowed_scms configuration
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji_b…
* Add flatpaks/ to the module-build-service SCMS configuration
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/mbs/co…
* Adjust the owner-sync-pagure script to handle flatpaks/
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2…
* Move or reimport existing Flatpak repositories
(modules/eog, modules/feedreader, modules/flatpak-common,
modules/flatpak-runtime,
modules/gnome-clocks, modules/gnome-tetravex, modules/quadrapassel)
Potential issues:
* We should probably move flatpak-common to the flatpaks/ namespace
for ease of discovery, but it isn’t in any way a flatpak, it’s just a
module that Flatpaks can depend on.
* The ability of modules to include other modules won’t work without
further adjustments to the MBS config.py (MODULES_ALLOW_REPOSITORY) -
I don't see this as useful functionality for Flatpaks.
Hi everybody,
I want to announce that the Anitya 0.14.0 was deployed on
staging (https://stg.release-monitoring.org/)
Feel free to test it.
Anitya 0.14.0 will be deployed on production next week if no breaking
issue will be found.
You can see changelog here
https://github.com/release-monitoring/anitya/releases/tag/0.14.0
There are plenty of changes in this version. Here are most noticeable:
* Delete cascade added to most db models - No orphaned packages or
mappings anymore \o/
* Logs page is reworked - Should be much more simpler
* Check is now done for all versions instead of only latest - No version
will be lost anymore
* Rate limit is now handled more efficiently - No Github project should
be skipped anymore
* New user management allowing simple promotion of users to admin - No
need to change configuration for every new admin
* project.version.update fedmsg topic now contains information about
ecosystem - This should help when you are looking for projects from Pypi
or Rubygems
* Support for Python 2.7 is now officially dropped
Thanks to everyone who contributed to this new version.
Regards,
mkonecny
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr…
Dear all,
You are kindly invited to the meeting:
Fedora koji outage on 2019-01-11 from 00:00:00 to 00:00:00 UTC
The meeting will be about:
Planned Outage - Koji Services - 2019-01-11 22:00 UTC
There will be an koji outage starting at 2019-01-11 22:00 UTC,
which will last approximately 4 days.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2019-01-11 22:00UTC'
Reason for outage:
The facility that houses the Fedora s390 server will have a major power outage starting 2019-01-11 22:00 UTC and ending 2019-01-14 22:00 UTC. During this time the s390 builders will not be available and all builds will be queued up until they are available and will not complete.
Affected Services:
koji and related services which make composes and builds
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7429
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
Source: https://apps.fedoraproject.org/calendar/meeting/9422/
Now that pungi has been updated on the bodhi backend machines
(https://pagure.io/fedora-infrastructure/issue/7484) I can re-enable
updates-testing for silverblue. Also added some removal of code
specific to f27.
- bodhi-pungi: re-enable testing ostree for silverblue
- bodhi-pungi: simplify now that f27 is EOL