DevHeads.net

Postings by Pierre-Yves

Decommissioning summershum

Good Morning Everyone,

The Fedora Infrastructure has been running a small service named summershum [1]
for a few years.
This service exploded all the archives uploaded in our lookaside cache,
calculated the md5, sha1, sha256 and sha512 hash of every files in these
archives
and stored them in a database.

Despite several attempts, we never managed to write a front-end to this service
to actually make it usable and useful.

To save some resources and free the mind of the Fedora Infrastructure team
members we have decided to decommission this service.
The database has been dumped and made avail

Decommissioning Darkserver

Good Morning Everyone,

As announced earlier [1] and after some discussion on the fedora devel list [2],
we are decommissioning the darkserver service.

Based on the discussion on the devel list, there is an use-case for such a tool
and potentially interest for it, but no-one has stepped up to fix the current
issues and our resources are limited.
We have dumped the database and uploaded it at:
<a href="https://infrastructure.fedoraproject.org/infra/db-dumps/darkserver-2018-04-10.dump.xz" title="https://infrastructure.fedoraproject.org/infra/db-dumps/darkserver-2018-04-10.dump.xz">https://infrastructure.fedoraproject.org/infra/db-dumps/darkserver-2018-...</a>
Feel free to grab it if you are interested in its content or wish to run a local
instance.

We are sorry to see thi

Call for users of darkserver

Good Morning Everyone,

The week before DevConf, a number of the members of the Fedora Infrastructure
met in Brno to discuss states and plans for the infrastructure.
One of the question that raised was about darkserver.

This application is available at: <a href="https://darkserver.fedoraproject.org/" title="https://darkserver.fedoraproject.org/">https://darkserver.fedoraproject.org/</a>
and is meant to:

enable developer tools to identify exact package builds from which process
images (e.g. core dumps) come. This can enable their analysis, debugging
profiling, by finding out where the rpm / elf / dwarf files may be found, so
they can download them.

Test gating enabled in Bodhi

Good Morning Fedorans!

On Thursday, a new version of Bodhi was deployed that enabled Bodhi to
gate updates based on test results. You may notice a "Test Gating
Status" message in the right have side of the page.

One thing to know about this is that there is currently a confusing
issue where Bodhi will say that the tests have failed when the tests
haven't finished running[0].

Planned Outage: nuancier - 2018/01/12 10:00 UTC

Planned Outage: apps.fedoraproject.org/nuancier 2018-01-12 10:00 UTC

There will be an outage starting at 2018-01-12 10:00 UTC, which will last
approximately 30 minutes,

To convert UTC to your local time, take a look at
<a href="http://fedoraproject.org/wiki/Infrastructure/UTCHowto" title="http://fedoraproject.org/wiki/Infrastructure/UTCHowto">http://fedoraproject.org/wiki/Infrastructure/UTCHowto</a> or run:

date -d '2018-01-12 10:00:00 UTC'

Reason for outage:

We need to update nuancier to its latest release which allows some time for the
moderators between the end of the submissions and the start of the votes.

Affected Services:

<a href="https://apps.fedoraproject.org/nuancier" title="https://apps.fedoraproject.org/nuancier">https://apps.fedoraproject.org/nuancier</a>

Contact Information:

Ticket Link: <a href="https://pa" title="https://pa">https://pa</a>

Intent to retire jenkins.fedorainfracloud.org

Dear all,

The Fedora Infrastructure team has had a jenkins instance running at
jenkins.fedorainfracloud.org for a little while now. This instance was
maintained on a best-effort basis though and we often had outage and issues when
upgrading it.
Originally the jenkins master was running on RHEL using the RPMs provided by
upstream jenkins. When jenkins became available in Fedora, we switched our
master to be Fedora using the RPMs from Fedora.

Main admin for nodejs packages

Good Morning Everyone,

I recently found out that some packages were not correctly migrated from pkgdb

Looking at a couple of ones in pkgdb, it seem the issue is basically that a group
has commit access to the package but no-one has commit or approveacls so during
the migration, the script was not able to find an user to set as main admin
(pagure not supporting having groups as main admin).

Is there anyone interested in becoming the main admin for these packages?

Here is the full list:

rpms/kaccounts-integration
rpms/kaccounts-providers
rpms/kde-cli-tools
rpms/kdecoration
rpms/kdeedu-data

Cleaning up the test-* namespaces

Good Morning Everyone,

A while ago we had the question about including tests in dist-git.

Pagure over dist-git: what changes?

Good morning everyone,

We're now in the final sprint before Pagure over dist-git is a real thing. This
is a great time and we're very excited to see it happen.
However this change brings other changes with it which are detailed below.

Point of contact in bugzilla

The future of the packager group for dist-git

Good Morning Everyone,

With pagure becoming a front-end to dist-git, I have been wondering about the
future of the packager group.

The packager group is currently used for a few things:
- tracking purpose, it's one of our biggest groups and also one of the most active
- members of the packager group can do official package review
- members of the packager group can become maintainer of a package

Someone can join this packager group in a few ways:
- Being sponsored by someone after having submitted one or more packages for review
- Being sponsored by someone after having offered to help main

Fedora CI effort/Interest Group

Dear all,

A small team of people interested in working on a Continuous Integration has
started looking into what it would take to add Continous Integration (CI) to our
current packaging and releasing workflow.
The current idea is to use fedora-atomic as a prototype product to port into
this workflow while keeping in mind other use-cases so that we could eventually
use this approach for the entire distribution (as opt-in).

Since there might be more people interested than the people who expressed their
interest, I invite anyone interested to join the mailing list:
<a href="https://lists.fedoraproject.o" title="https://lists.fedoraproject.o">https://lists.fedoraproject.o</a>

How attached are we to branch ACLs? -- Should we kill pkgdb?

Hi everyone,

As I am working on bringing pagure as a front-end to our dist-git, a question is
troubling me.

Currently ACLs are stored in pkgdb, it allows having a per-branch ACL model,
which in itself is quite cool, but I wonder: is it that useful?

I know pkgdb brings us other things too and I am explicitely ignoring them here
because I think we can find solutions for them, which may even have benefits
over our current processes.

So, does per-branch ACLs make sense to you? Have you had cases where you thought
it was good/bad?

Call for help contacting contributor: aledvink

Dear all,

Packagers, members of the fedorabugs group and people having a 'watchbugzilla'
ACL in pkgdb must have a bugzilla account attached to the email they set in the
Fedora Account System (FAS).
This is mandatory to allow ACLs to be propagated from pkgdb to bugzilla, allowing
the right person to be made assignee or to be cc'ed on bug reports of packages.

There are currently an users who is not following this rule and have been for
quite a while, despite our attempts to contact them:

* aledvink, FAS email: aledvink -- centrum.cz
PoC of 2 packages - co-maintains 7 packages
https:/

Call for help contacting contributor: spike

Dear all,

Packagers, members of the fedorabugs group and people having a 'watchbugzilla'
ACL in pkgdb must have a bugzilla account attached to the email they set in the
Fedora Account System (FAS).
This is mandatory to allow ACLs to be propagated from pkgdb to bugzilla, allowing
the right person to be made assignee or to be cc'ed on bug reports of packages.

There are currently an users who is not following this rule and have been for
quite a while, despite our attempts to contact them:

* spike, FAS email: spikefedora -- gmail.com
PoC of 19 packages - co-maintains 15 packages

If anyon

Call for help contacting contributors

Dear all,

Packagers, members of the fedorabugs group and people having a 'watchbugzilla'
ACL in pkgdb must have a bugzilla account attached to the email they set in the
Fedora Account System (FAS).
This is mandatory to allow ACLs to be propagated from pkgdb to bugzilla, allowing
the right person to be made assignee or to be cc'ed on bug reports of packages.

There are currently a few users who are not following this rule and have not
been for quite a while, despite our attempts to contact them:

* jackprice, FAS email: jackprice -- outlook.com
watches 1 package
* vjancik, FAS email: v

Namespacing in pkgdb

Hello everyone,

The Fedora infrastructure and the release-engineering teams have worked together
to begin to add namespacing to our infrastructure.

Namespacing in pkgdb

Hello everyone,

The Fedora infrastructure and the release-engineering teams have worked together
to begin to add namespacing to our infrastructure.

fedora-packages rebuild/upgrade

Hello,

In the coming hours we will be both upgrading fedora-packages [1] to a new
version (relying on mdapi [2]) and rebuilding its index.

This should take a couple of hours during which fedora-packages will not be
available.

Contact info for FAS user: linuxdonald

Hi everyone,

Fedora infrastructure is trying to reach the FAS user linuxdonald.

Non-responsive procedure for David Gay

Good morning,

Recently David Gay aka oddshocks has left Red Hat and we have not been able to
contact him since.
There are two packages for which he is Point of Contact:
- python-fedimg (Fedora & EPEL)
- python-cpio (EPEL 5 & 6)

We would like to ask anyone that can contact him to ask him what he would like
to see happening on these packages.
Otherwise we will orphan them and let person interested in them pick them up.

Thanks for your help,
Pierre

Contact info for FAS user: vicodan

Hi everyone,

Fedora infrastructure is trying to reach the FAS user vicodan.

Contact info for FAS user: anishpatil

Hi everyone,

Fedora infrastructure is trying to reach the FAS user anishpatil.
There is a gmail email associated to this account but apparently it is not enough
to contact this person.

Does someone know how to contact anishpatil?

If we do not manage to contact anish, we will have to de-activate the account
(which can then be re-activated by logging in FAS and changing the flag) and we
will also have to figure out what to do with the packages this user is the PoC
of.

Thanks for your help,
Pierre
-- for the Infrastructure team

Contact Jorge Torres

Hi all,

The user: jorge 'Jorge Torres' < ... at gmail dot com> is a member of the
fedorabugs group and as such, it is required that the email set in FAS (the one
mentioned above) corresponds to an account on bugzilla (in order to sync ACLs
from FAS to bugzilla).

In the case of Jorge, this is not the case, more over, when emailing him, we get
the reply:

< ... at gmail dot com>: host gmail-smtp-in.l.google.com[74.125.20.26] said:
550-5.1.1 The email account that you tried to reach does not exist.

Call for testers: distgit gitolite3@rhel7

Dear testers,

Mathieu Bridon and I have been working for a little while now on migrating our
existing distgit solution from RHEL6 to RHEL7, this as involved three migrations
in one:
* Migrate from RHEL6 to RHEL7
* Migrate from puppet to Ansible
* Migrate from gitolite2 to gitolite3
All this running now with SELinux enforcing (Many thanks to tfirg on #selinux for
his more than generous help on this point).

We are at the point were we are satisfied with it and all our tests have passed.
So before we actually migrate our production instance we would like to ask for
broader testing.

How to test

Mass reassign and orphan: steve

Dear all,

This morning I processed another round of point of contact changes.
According to <a href="https://fedorahosted.org/fesco/ticket/1233" title="https://fedorahosted.org/fesco/ticket/1233">https://fedorahosted.org/fesco/ticket/1233</a>, all the perl-* packages
from the FAS user steve have been reassigned to psabata and the rest of it
orphaned.

Here below is the full list, orphaned first, perl then.

Have a nice day,
Pierre

List of packages orphaned:

altermime -- Alter MIME-encoded mailpacks ( epel7 el6 el5 )
celestia -- OpenGL real-time visual space simulation ( master f21 f20 f19 el6
el5 )
clamav -- End-user tools for the Clam Antivirus scanner ( epel7 el6 el5 )
cone -- CONE mail reader

Mass orphan: iarnell

Hi all,

Following ticket: <a href="https://fedorahosted.org/fesco/ticket/1360" title="https://fedorahosted.org/fesco/ticket/1360">https://fedorahosted.org/fesco/ticket/1360</a> I have just
orphaned all the packages from iarnell on all branches.

During the mass-orphaned we found out a bug in pkgdb making it orphaned all the
branches of the package, not just the ones for which the user is POC.
Unfortunately, this means we have orphaned branches that were maintained by
someone else than Iarnell.

Call for beta-testers for group maintainership

Dear all,

A long desired and awaited feature for pkgdb2 is the possibility to have FAS
groups maintain packages.

The idea is the following:
- You have a FAS group
- People are members of this group
- This group can be given commit or even be made point of contact of packages
on pkgdb
- If the group has commit, members of the group will have commits (so you don't
need anymore to ask for ACL in pkgdb, you can just ask to be added in the
group in FAS).

After some preliminary testing with positive results, I would like to call for
more testers.

Ideally, if we could get a few groups of no

Future changes in the new package and new branch processes

Dear all,

In the last months, Till and I together with infrastructure and
release-engineering have been thinking and working on how we could improve the
current workflow for new package and new branch.

To give you an idea, this is the current workflow:

Current new-package procedure:
==============================

* packager opens a review-request on bugzilla
* reviewer sets the fedora-review flag to ?
* reviewer does the review
* reviewer sets the fedora-review flag to +
* packager creates the scm-request and set fedora-cvs flag to ?
* cvsadmin checks the review (check reviewer is a packag

Call for testers for FMN

Dear all,

Pkgdb2 is now running for a little over two months. It seems that most of you
like it which is appreciated :)

However, one of the annoyance from Pkgdb1 has not disapeared.

PkgDB, pending ACL requests

Good Morning everyone!

In the version 1.13 of pkgdb2 a new API endpoint has been added that just
provide the list of pending ACL requests:
<a href="https://admin.fedoraproject.org/pkgdb/api/pendingacls" title="https://admin.fedoraproject.org/pkgdb/api/pendingacls">https://admin.fedoraproject.org/pkgdb/api/pendingacls</a>

I just wanted to share with you the first line of its output:

# Number of requests pending: 5492

Now I do realize that the branching that occured yesterday is blowing up this
number compared to yesterday, but please be careful to log in pkgdb2 once a
while and check out the pending ACL requests requiring your attention.

Note: Since the same pkgdb2 release, there is a small notification showing-