rel-eng October 2014

rel-eng@lists.fedoraproject.org

16 participants
143 discussions

#6009: Curious about python-sqlalchemy on epel7
by Fedora Release Engineering 11 Nov '14

11 Nov '14

#6009: Curious about python-sqlalchemy on epel7 --------------------+------------------------ Reporter: pingou | Owner: rel-eng@… Type: defect | Status: new Milestone: | Component: epel Keywords: | Blocked By: Blocking: | --------------------+------------------------ According to datagrepper python-sqlalchemy was branched for epel7 9 months ago: https://apps.fedoraproject.org/datagrepper/id?id=2013-b8045ad9-1985-416a- 92ff-3c6630f17642&is_raw=true&size=extra-large Since then, I can find ACL approved/dropped but no orphan nor retirement. Same thing in pkgdb2's logs: https://admin.fedoraproject.org/pkgdb/admin/log/?package=python-sqlalchemy Nothing special in git: http://pkgs.fedoraproject.org/cgit/python- sqlalchemy.git/log/?h=epel7 So, what happened with this branch? How has it end-up being blocked in koji and marked as retired in pkgdb w/o pkgdb or datagrepper knowing about it. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6009> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

#5679: merge buildbranched/buildrawhide into a single script
by Fedora Release Engineering 10 Nov '14

10 Nov '14

#5679: merge buildbranched/buildrawhide into a single script -----------------------------+------------------------ Reporter: ausil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ in order to simplify things it would be good to make a single script to build rawhide and branched. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5679> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#6011: Request for override tag for tomcatjss-7.1.1-1.fc20 and fc21 in tomcatjss FC20 and FC21 branches
by Fedora Release Engineering 10 Nov '14

10 Nov '14

#6011: Request for override tag for tomcatjss-7.1.1-1.fc20 and fc21 in tomcatjss FC20 and FC21 branches -----------------------------+------------------------ Reporter: cfu | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ we'd like to build tomcatjss-7.1.1-1.fc20 and fc21 which both have a dependency on jss-4.2.6-35 which is now waiting for karma. We'd like to request for a permanent override flag. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6011> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 6

#6024: Changes to the process of unretire a dead package
by Fedora Release Engineering 10 Nov '14

10 Nov '14

#6024: Changes to the process of unretire a dead package -----------------------------+------------------------ Reporter: hannes | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 20 Final | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi all, at the moment, when a new package was re-reviewed and the git request was processed the original maintainer, who perhaps initially imported the package has still commit access to various branches, most importantly to the devel branch. In this particular case the original maintainer stopped working on the package in 2010, at least that was when he last initiated a build on koji. [1] I then took it over until it was retired by me, because upstream was dead and it wasn't really necessary any more. It was then again picked up by a different upstream, who contacted me and asked me to introduce it to fedora again. I did so and filed a review ticket and did all the necessary steps. [2] And then after it was approved and the git process was done, I noticed in pkgdb, that the original maintainer was still listed there. [3] I mean of course this is not a big problem, but if he really would be interested to me it would seem more natural, that he then requests co- maintainership and don't gets it automatically. -johannes [1] http://koji.fedoraproject.org/koji/packageinfo?packageID=3984 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1153302 [3] https://admin.fedoraproject.org/pkgdb/package/tilda/ -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6024> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 10

#6014: multiple builds in primary koji are lackign arm buildroot info
by Fedora Release Engineering 10 Nov '14

10 Nov '14

#6014: multiple builds in primary koji are lackign arm buildroot info -----------------------------+------------------------ Reporter: sharkcz | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: koji Keywords: meeting | Blocked By: Blocking: | -----------------------------+------------------------ There are multiple builds in primary koji run during 10/02 that are lacking the content for arm buildroots breaking builds in secondary kojis http://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=2444699 (ice-3.5.1-13.fc21) http://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=2443844 (java-1.8.0-openjdk-1.8.0.20-12.b26.fc21) http://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=2443370 (tracker-0.16.4-4.fc20) and more -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6014> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 7

#6025: Unblock xpa package in current release
by Fedora Release Engineering 07 Nov '14

07 Nov '14

#6025: Unblock xpa package in current release -----------------------------+------------------------ Reporter: sergiopr | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, this ticket is to request the unblocking of the package xpa in the current release. xpa was retired a while ago, This is the re-review ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1157794 -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6025> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

#6010: Create Fedora 21 Beta test compose (TC) and release candidate (RC)
by Fedora Release Engineering 04 Nov '14

04 Nov '14

#6010: Create Fedora 21 Beta test compose (TC) and release candidate (RC) ----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ Time flies, so it's time for Beta... Please build a Fedora 21 Beta Test Compose. I don't believe there are any special build requests at this point in time, let's just fire a TC1 and see where we stand. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6010> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 23

#6015: Remove phpMyAdmin3 packages from EPEL-5
by Fedora Release Engineering 01 Nov '14

01 Nov '14

#6015: Remove phpMyAdmin3 packages from EPEL-5 --------------------+------------------------ Reporter: robert | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: epel Keywords: | Blocked By: Blocking: | --------------------+------------------------ I retired the el5 branch of phpMyAdmin3 as it is superseeded by phpMyAdmin4 - however the phpMyAdmin3 packages should be removed from the EPEL repositories if possible (unmaintained, outdated and contain various known security vulnerabilities). A standard "yum update" should upgrade existing phpMyAdmin3 installations to phpMyAdmin4. Thanks, Robert -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6015> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

[PATCH] Don't suppress error messages
by Mathieu Bridon 31 Oct '14

31 Oct '14

If a failure occured when trying to create the cache folder, mash would just silently ignore the error and happily continue cranking along. It might of course fail later on, but the problem is impossible to debug if errors are silently suppressed. However, if the error is merely that the directory already exists (as opposed to a permission issue, for example), then that is fine to ignore. Likewise, if a failure occurs when trying to download, merely saying "can't download" is not helpful. Adding the actual error message makes it easier to figure out what went wrong. --- mash/__init__.py | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/mash/__init__.py b/mash/__init__.py index 566b8c1..27cdc47 100644 --- a/mash/__init__.py +++ b/mash/__init__.py @@ -12,6 +12,7 @@ # with this program; if not, write to the Free Software Foundation, Inc., # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +import errno import glob import os import logging @@ -269,8 +270,11 @@ class Mash: path = os.path.join(koji.pathinfo.build(builds_hash[pkg['build_id']]), koji.pathinfo.rpm(pkg)) try: os.mkdir(os.path.dirname(cachepath)) - except: - pass + except Exception as e: + if e.errno != errno.EEXIST: + # If the directory already exists, that's fine + self.logger.error(e) + try: result = urlgrabber.grabber.urlgrab(path, cachepath) except: @@ -279,8 +283,9 @@ class Mash: path = os.path.join(koji.pathinfo.build(builds_hash[pkg['build_id']]), koji.pathinfo.rpm(pkg)) try: result = urlgrabber.grabber.urlgrab(path, cachepath) - except: - self.logger.error("ERROR: can't download %s from %s" % (nevra(pkg), path)) + except Exception as e: + self.logger.error("ERROR: can't download %s from %s: %s" + % (nevra(pkg), path, e)) return None fd = open(result) -- 2.1.0

4 8

[PATCHES] Sprinting on rpkg during PyCon-Fr
by Mathieu Bridon 31 Oct '14

31 Oct '14

>From Saturday to Tuesday was PyCon-Fr, here in Lyon, so I used the time to hack a bit on rpkg. The result is a pretty big changeset: .gitignore | 1 + setup.cfg | 5 + setup.py | 38 ++----- src/pyrpkg/__init__.py | 357 +++++++++++++++++++++++++++++++------------------------------- src/pyrpkg/cli.py | 976 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------------------------------------------------------- src/rpkg_man_page.py | 11 +- test/commands/__init__.py | 110 ++++++++++++++++++++ test/commands/test_add_tag.py | 156 ++++++++++++++++++++++++++++ test/commands/test_clone.py | 88 ++++++++++++++++ test/commands/test_delete_tag.py | 51 +++++++++ test/commands/test_list_tag.py | 159 ++++++++++++++++++++++++++++ test/test_gitgnore.py | 83 +++++++++++++++ 12 files changed, 1274 insertions(+), 761 deletions(-) Now, out of these 1274 insertions, 647 are new unit tests. So if you remove that from the count, the overall diff stat is rather: 6 files changed, 627 insertions(+), 761 deletions(-) That's right, keeping the same features, fixing a couple of bugs, and making us almost entirely Flake8-compliant, I'm still removing more 100 lines of code. Not bad. :) Speaking of Flake8 compliance, the remaining problems are all stuff I'd rather not touch right now, in the middle of what are mostly trivial changes. We'll get there at some point, though. To make review easier, here's an outline of what the patches do. * [PATCH 01/20] Some more PEP8 * [PATCH 02/20] Remove unused import Just some trivial changes to the setup.py script, to make the next commit easier to review. * [PATCH 03/20] tests: Use nose This makes use of the awesome 'nose' testing library, removing some home-grown code, and adding a pretty nice feature: a report of the code coverage of the unit tests. * [PATCH 04/20] tests: Ensure proper functioning of GitIgnore * [PATCH 05/20] gitignore: We're not modified any more after we wrote * [PATCH 06/20] gitignore: Make sure each line ends with a \n These add some unit tests for our handling of .gitignore files, which actually found 2 bugs in the code. Hurray for unit tests! * [PATCH 07/20] tests: Ensure functioning of Commands.clone * [PATCH 08/20] tests: Factor out some code This sets up the necessary conditions for easily testing all the interactions with Git repositories, and actually tests the clone command. * [PATCH 09/20] tests: Ensure proper functioning of Commands.add_tag * [PATCH 10/20] add_tag: Run the tag command in the right directory These add some unit tests for the add_tag command, which actually found a bug in the code. One more victory for unit tests! * [PATCH 11/20] tests: Ensure functioning of Commands.delete_tag * [PATCH 12/20] delete_tag: Stop executing a command This adds some unit tests for the delete_tag command. And once it is tested, it is easy to move away from subprocessing the git cli, which makes the code nicer and avoids the overhead of forking child processes. Plus, pyrpkg is a library, and it's generally a terrible idea to subprocess command line tools inside a library. * [PATCH 13/20] list_tags: Fix the docstring * [PATCH 14/20] list_tags: Stop executing a command * [PATCH 15/20] tests: Ensure functioning of Commands.list_tag These greatly improve the list_tag command. The second patch is in fact necessary to make the method testable. * [PATCH 16/20] Fix typo * [PATCH 17/20] Simplify some code Just two trivial changes I came up with while idly reading the source code. * [PATCH 18/20] Fix some flake8 issues * [PATCH 19/20] Fix some more Flake8 issues * [PATCH 20/20] Massive Flake8 fix These are pretty massive patches, but they are worth it: they make the code easier to read and "get into" for newcomers by following standard Python conventions, removing unused variables and imports, etc... All in all, they even remove lines of code. The diffstat for just these 3 changes is: 3 files changed, 577 insertions(+), 709 deletions(-)

2 21

← Newer
1
2
3
4
5
6
7
8
9
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng October 2014