Le blog de pingou

To content | To menu | To search

Tuesday, March 24 2015

New package & new branch process

A little while ago, I blogged about the new package and new branch request processes.

These changes have been pushed to production yesterday.

What does this change for you, packager?

New package

If you already a packager, you know the current process to get packages into Fedora, you know that once your package has been approved on bugzilla, you have to file a SCM request.

With the new process, this step is no longer necessary. You can directly go to pkgdb and file the request there.

From there admins will review the package review on bugzilla and create the package in pkgdb (or refuse with an explanation).

New branch

If your package is already in Fedora, you can now directly request a new branch in pkgdb. Here there are multiple options

  • You have approveacls on the package (thus you are a package admin) and the request is regarding a new Fedora branch: The branch will be created automatically
  • You have approveacls on the package (thus you are a package admin) and the request is regarding a new EPEL branch: The request will be submitted to the pkgdb admins who will process it in their next run
  • You do not have approveacls on the package, then your request will be marked as: `Pending`, this means that the admins of the package have one week to react. They can either approve your request and by setting it to Awaiting Review, or they can decline the request (for which they must specify a reason). After this one week (or sooner if the package admin set the request to Awaiting Review) the pkgdb admin will process the request like they do with the other.

Note: Even with this new workflow, requests are still manually reviewed, so the requests will not necessarily be processed faster (but if it is easier for the admins, they may run it more often!).

What does this change for you, admins?

Hopefully, the process will be much simpler for you. In short

  • no need to log onto any system, you can do everything from your own machine and it should work out of the box
  • much more automated testing (including checking if a package is present in RHEL and on which arch for EPEL requests)
  • one tool to process the requests: pkgdb-admin distributed as part of packagedb-cli (aka: pkgdb-cli)



I hope this process makes sense to you and will make your life easier.

You are welcome to already use these processes, just let us know if you run into some problems, but for the time being both the old and the new processes are supported :-)

Thursday, January 22 2015

New branch request process

A little while ago I blogged about a new process to request a new branch on an existing package.

The code to support this change is now under review but I thought I should document the workflow a little bit, so here is how I tried to design things:

pkgdb_new_branch_flow_2.png

Ideally, when the branch is approved and created in pkgdb by the admin, pkgdb will send a message on fedmsg, message that will be seen by a fedmsg-consummer that will automatically update the git repos within, say 2 minutes. That last part if almost ready and hopefully will be running soon.

Wednesday, July 23 2014

New package, new branch, new workflow?

If you are a Fedora packager, you are probably aware of the new pkgdb.

One question which has been raised by this new version is: should we change the process to request new branches or integrate new packages in the distribution.

The discussion has occurred on the rel-eng mailing list but I'm gonna try to summarize here what the process is today and what it might become in the coming weeks.

Current new-package procedure:
  1. packager opens a review-request on bugzilla
  2. reviewer sets the fedora-review flag to ?
  3. reviewer does the review
  4. reviewer sets the fedora-review flag to +
  5. packager creates the scm-request and set fedora-cvs flag to ?
  6. cvsadmin checks the review (check reviewer is a packager)
  7. cvsadmin processes the scm-request (create git repo, create package in pkgdb)
  8. cvsadmin sets fedora-cvs flag to +
New procedure
  1. packager opens a review-request on bugzilla
  2. reviewer sets the fedora-review flag to ?
  3. reviewer does the review
  4. reviewer sets the fedora-review flag to +
  5. packager goes to pkgdb2 to request new package (specifying: package name, package summary, package branches, bugzilla ticket)
  6. requests added to the scm admin queue
  7. cvsadmin checks the review (check reviewer is a packager¹)
  8. cvsadmin approves the creation of the package in pkgdb
  9. package creation is broadcasted on fedmsg
  10. fedora-cvs flag set to + on bugzilla
  11. git adjusted automatically

Keeping the fedora-cvs flag in bugzilla allows to perform a regular (daily?) check that there are no fedora-review flag set as + that have been approved in pkgdb and whose fedmsg message hasn't been processed.

Looking at the number, it looks like there are more steps on the new procedure but eventually, most of them can be automated.

New branch process

For new branches, the process would be very similar:

  1. packager goes to pkgdb2 to request new branch
  2. requests added to the scm admin queue
  3. cvsadmin checks the request (requester is a packager...)
  4. cvsadmin approves the creation of the branch in pkgdb
  5. branch creation is broadcasted on fedmsg
  6. git adjusted automatically

Tuesday, December 17 2013

Fedora package build history

Recently I have been thinking about a way to do mass-rebuild but only of packages that have not been built in a while (since the last release?).

At the moment, we only do mass-rebuild when there is a specific need to, for example a new version of GCC.

This is a very specific process which is ran over multiple days and just rebuilds all the packages. As a results, some packages that are of very low maintenance may just seat around, un-touched until the next mass-rebuild.

I was wondering if we could not simply take all the packages on rawhide and run, say once a month (or once a week, every day?), check when their last successfull build was and if older than X (to be defined), do a simple scratch build of the package. We could query koji or fedmsg via datagrepper to get the date of the last successful build of the package.

So technically it is duable, in theory it makes sense but the question is, in practice does it?

The first check to assess this is simply looking at the distribution last successfull dates of the packages.

So I wrote a small script querying the packagedb to get the list of all the packages and then queries datagrepper to retrieve the date of the last successful build. The number of days between this date and today is then computed and the output provides the number of packages that have been rebuild on each day.

Graphically it looks like this: On the X axis is presented the number of packages built on that day, on the Y axis is how many days ago that day was.

last_build.png

Converted to a log scale, we get: On the X axis is a log of the number of packages built on that day, on the Y axis is how many days ago that day was.

last_build_log.png

To provide some more statistics:

  • 14397 packages were checked
  • 49 packages were built yesterday (day 0, when the data was gathered),
  • 1 package has not been successfully built since 271 days ago
  • 66 packages have not been sucessfully re-built for 200 days or more
  • 11418 packages have not been sucessfully re-built for 100 days or more
  • The two peaks that can be seen are from 132 and 133 days ago (last mass-rebuild?)



Is this something worth persuing? Should we automatically re-build packages after a while and report in case the build fails?

What do you think?

Monday, July 16 2012

libdivecomputer & subsurface

rpm.png

A small gift to our friend divers running Fedora

Continue reading...

Sunday, November 13 2011

Fedora-review, help yourself!

rpm.pngsource.png

Fedora-review is a tool to speed up review process

Continue reading...

Saturday, November 12 2011

New R2spec \ó/

rpm.pngsource.png

Re-write of R2spec in the version 4.0.0

Continue reading...

Thursday, November 10 2011

Retrieve specific source from github

rpm.png

URL to tarball for github projects

Continue reading...

Friday, August 5 2011

PackageDB-cli 1.1.0

rpm.pngsource.png

Version 1.1.0 du client text pour pkgdb.

Release 1.1.0 of the command-line interface for pkgdb.

Continue reading...

Friday, December 10 2010

Dependency graph

source.png

A small script to generate the dependency graph from spec file

Un petit script pour générer le graph des dépendances à partir de fichier spec

Continue reading...

Saturday, June 5 2010

reviewHelper

source.png

Automate some of the step needed for a review

Automatiser quelques unes des étapes pour la revue d'un paquet RPM

Continue reading...

Thursday, May 13 2010

R-autoreview

source.png

A script to help to review R packages

Un script pour aider à faire des revues de paquets R

Continue reading...

Friday, April 23 2010

RPM repository for R packages

A RPM repository for R packages is being built

Un dépôts de RPM pour les bibliothèques R est en cours de création

Continue reading...

Thursday, March 25 2010

R2rpm on cran

Building cran RPM via R2rpm

Construire des RPMs du cran avec R2rpm

Continue reading...

Wednesday, March 24 2010

R2spec / R2rpm

rpm.pngsource.png

New version of R2spec in the pipes

Une nouvelle version de R2spec dans les tuyaux

Continue reading...

Tuesday, August 11 2009

makeBuild.py

source.png

A small script to automate the build in different branch

Un petit script pour faire le build de rpm dans différentes branches.

Continue reading...

Sunday, August 2 2009

R2spec version 2.5.3

rpm.pngsource.png

New release of R2spec

Nouvelle version de R2spec

Continue reading...

Sunday, March 22 2009

R2spec version .2.5.2

rpm.pngsource.png

New release of R2spec

Nouvelle version de R2spec

Continue reading...

Tuesday, February 10 2009

Guake Git version

New release of Guake from the git repo

Nouvelle version de Guake issue du repo Git

Continue reading...

Wednesday, October 8 2008

R2spec version 2.5.1

rpm.pngsource.png

New release of R2spec

Nouvelle version de R2spec

Continue reading...

- page 1 of 3