#6024: Changes to the process of unretire a dead package
by Fedora Release Engineering
#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
9 years, 5 months
#6010: Create Fedora 21 Beta test compose (TC) and release candidate (RC)
by Fedora Release Engineering
#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
9 years, 6 months
#6015: Remove phpMyAdmin3 packages from EPEL-5
by Fedora Release Engineering
#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
9 years, 6 months
[PATCH] Don't suppress error messages
by Mathieu Bridon
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
9 years, 6 months
[PATCHES] Sprinting on rpkg during PyCon-Fr
by Mathieu Bridon
>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(-)
9 years, 6 months