internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: fedora-infra/bodhi

Issue:
Bodhi metrics page is broken
Both in staging and production, visiting the Bodhi metrics page throws a 500 Error:
https://bodhi.fedoraproject.org/metrics
`'NoneType' object has no attribute 'groups'`


Discussion:

Resolving patch:
diff --git a/bodhi/server/models.py b/bodhi/server/models.py
--- a/bodhi/server/models.py
+++ b/bodhi/server/models.py
@@ -812,7 +812,7 @@ def version_int(self):
         Returns:
             int: The version of the release.
         """
-        regex = re.compile(r'\D+(\d+)[CM]?$')
+        regex = re.compile(r'\D+(\d+)[CMF]?$')
         return int(regex.match(self.name).groups()[0])
 
     @property


Test patch:
diff --git a/bodhi/tests/server/test_models.py b/bodhi/tests/server/test_models.py
--- a/bodhi/tests/server/test_models.py
+++ b/bodhi/tests/server/test_models.py
@@ -808,6 +808,38 @@ def test_all_releases(self):
         assert releases is model.Release.all_releases()
 
 
+class TestReleaseFlatpak(ModelTest):
+    """Unit test case for the ``Release`` model for flatpak releases."""
+    klass = model.Release
+    attrs = dict(
+        name=u"F29F",
+        long_name=u"Fedora 29 Flatpaks",
+        id_prefix=u"FEDORA-FLATPAK",
+        version=u'29',
+        branch=u'f29',
+        dist_tag=u"f29-flatpak",
+        stable_tag=u"f29-flatpak-updates",
+        testing_tag=u"f29-flatpak-updates-testing",
+        candidate_tag=u"f29-flatpak-updates-candidate",
+        pending_signing_tag=u"",
+        pending_testing_tag=u"f29-flatpak-updates-testing-pending",
+        pending_stable_tag=u"f29-flatpak-updates-pending",
+        override_tag=u"f29-flatpak-override",
+        state=model.ReleaseState.current,
+        composed_by_bodhi=True)
+
+    def test_version_int(self):
+        self.assertEqual(self.obj.version_int, 29)
+
+    def test_all_releases(self):
+        releases = model.Release.all_releases()
+
+        state = ReleaseState.from_string(list(releases.keys())[0])
+        assert 'long_name' in releases[state.value][0], releases
+        # Make sure it's the same cached object
+        assert releases is model.Release.all_releases()
+
+
 class MockWiki(object):
     """ Mocked simplemediawiki.MediaWiki class. """
     def __init__(self, response):
Repository: fedora-infra/bodhi

Issue:
The search bar does not work in staging
I have so far been unable to reproduce the problem in the development environment, but I am unable to get the search bar to work in staging. It seems that the code in ```bodhi/server/static/js/search.js``` does not get executed on page load, but I do not know why yet.


Discussion:
@puiterwijk and I looked at this today while clipping along at 200 km/h. It seems that Bodhi has hardcoded the hostname ```hub.fedoraproject.org``` in its [live.js](https://github.com/fedora-infra/bodhi/blob/3.8.1/bodhi/server/static/js/live.js). The content security policy does not allow staging Bodhi to access production hub.fedoraproject.org. This happens during ```document.ready()```, which is also responsible for setting up the search bar.

To fix this, we believe that we should be able to make this a setting in Bodhi's configuration, and configure staging to use ```hub.stg.fedoraproject.org```.
I believe this issue has existed for a while and is not a regression in 3.9.0. Thus, I am downgrading it to high priority and will not consider it to be a release blocker.

Resolving patch:
diff --git a/bodhi/server/config.py b/bodhi/server/config.py
--- a/bodhi/server/config.py
+++ b/bodhi/server/config.py
@@ -428,6 +428,9 @@ class BodhiConfig(dict):
         'fedmsg_enabled': {
             'value': False,
             'validator': _validate_bool},
+        'fedmsg_gateway': {
+            'value': 'wss://hub.fedoraproject.org:9939',
+            'validator': str},
         'file_url': {
             'value': 'https://download.fedoraproject.org/pub/fedora/linux/updates',
             'validator': str},


Test patch:
Repository: fedora-infra/bodhi

Issue:
Add logs at every place that expires buildroot overrides
Some users have been having trouble with buildroot overrides getting unexpectedly untagged in Koji, and according to Koji the Bodhi user is the one untagging it. Unfortunately, Bodhi does not currently emit log messages when ```BuildrootOverride.expire()``` is called, so it is not easy to tell which code path is responsible for this.

We should find all the calls to ```BuildrootOverride.expire()``` and add log messages to explain *why* it is being called, for each one. This way we will have more useful debugging information in the future.


Discussion:
I'll take a shot at this before my PTO next week.
Looks like I need to be added to the org or project before I can assign this to myself.

Resolving patch:
diff --git a/bodhi/server/consumers/composer.py b/bodhi/server/consumers/composer.py
--- a/bodhi/server/consumers/composer.py
+++ b/bodhi/server/consumers/composer.py
@@ -608,6 +608,7 @@ def expire_buildroot_overrides(self):
                 for build in update.builds:
                     if build.override:
                         try:
+                            log.debug(f"Expiring BRO for {build.nvr} because it is being pushed.")
                             build.override.expire()
                         except Exception:
                             log.exception('Problem expiring override')
diff --git a/bodhi/server/models.py b/bodhi/server/models.py
--- a/bodhi/server/models.py
+++ b/bodhi/server/models.py
@@ -2061,6 +2061,7 @@ def edit(cls, request, data):
 
                 # Expire any associated buildroot override
                 if b.override:
+                    log.debug(f"Expiring BRO for {b.nvr} because the build is unpushed.")
                     b.override.expire()
                 else:
                     # Only delete the Build entity if it isn't associated with
@@ -4212,6 +4213,7 @@ def new(cls, request, **data):
         if old_build is not None and old_build.override is not None:
             # There already is a buildroot override for an older build of this
             # package in this release. Expire it
+            log.debug(f"Expiring BRO for {old_build.nvr} because it's superseded by {build.nvr}.")
             old_build.override.expire()
             db.add(old_build.override)
 
@@ -4256,6 +4258,7 @@ def edit(cls, request, **data):
             override.enable()
 
         elif data['expired']:
+            log.debug(f"Expiring BRO for {override.build.nvr} because it was edited.")
             override.expire()
 
         db.add(override)
diff --git a/bodhi/server/scripts/expire_overrides.py b/bodhi/server/scripts/expire_overrides.py
--- a/bodhi/server/scripts/expire_overrides.py
+++ b/bodhi/server/scripts/expire_overrides.py
@@ -75,6 +75,7 @@ def main(argv=sys.argv):
         log.info("Expiring %d buildroot overrides...", count)
 
         for override in overrides:
+            log.debug(f"Expiring BRO for {override.build.nvr} because it's due to expire.")
             override.expire()
             db.add(override)
             log.info("Expired %s" % override.build.nvr)


Test patch:
Repository: fedora-infra/bodhi

Issue:
HTTP 500 when viewing composes
I saw this when visiting https://bodhi.fedoraproject.org/composes/ just now:

```
500 Internal Server Error

Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/pyramid_mako/__init__.py", line 148, in __call__ result = template.render_unicode(**system) File "/usr/lib/python3.7/site-packages/mako/template.py", line 471, in render_unicode as_unicode=True) File "/usr/lib/python3.7/site-packages/mako/runtime.py", line 838, in _render **_kwargs_for_callable(callable_, data)) File "/usr/lib/python3.7/site-packages/mako/runtime.py", line 873, in _render_context _exec_template(inherit, lclcontext, args=args, kwargs=kwargs) File "/usr/lib/python3.7/site-packages/mako/runtime.py", line 899, in _exec_template callable_(context, *args, **kwargs) File "/usr/lib/python3.7/site-packages/bodhi/server/templates/master.html", line 189, in render_body ${self.body()} File "/usr/lib/python3.7/site-packages/bodhi/server/templates/composes.html", line 19, in render_body ${ self.util.composestate2html(compose.state) | n } File "/usr/lib/python3.7/site-packages/bodhi/server/util.py", line 525, in composestate2html }[state.value] KeyError: 'syncing_repo'
```


Discussion:

Resolving patch:
diff --git a/bodhi/server/util.py b/bodhi/server/util.py
--- a/bodhi/server/util.py
+++ b/bodhi/server/util.py
@@ -520,6 +520,8 @@ def composestate2html(context, state):
         'punging': 'warning',
         'notifying': 'warning',
         'cleaning': 'warning',
+        'syncing_repo': 'warning',
+        'signing_repo': 'warning',
         'success': 'success',
         'failed': 'danger',
     }[state.value]


Test patch:
diff --git a/bodhi/tests/server/test_util.py b/bodhi/tests/server/test_util.py
--- a/bodhi/tests/server/test_util.py
+++ b/bodhi/tests/server/test_util.py
@@ -451,6 +451,18 @@ def test_cleaning(self):
         self.assertEqual(util.composestate2html(None, ComposeState.cleaning),
                          "<span class='label label-warning'>Cleaning old composes</span>")
 
+    def test_syncing_repo(self):
+        """Assert correct return value with the syncing_repo state."""
+        self.assertEqual(
+            util.composestate2html(None, ComposeState.syncing_repo),
+            "<span class='label label-warning'>Wait for the repo to hit the master mirror</span>",
+        )
+
+    def test_signing_repo(self):
+        """Assert correct return value with the signing_repo state."""
+        self.assertEqual(util.composestate2html(None, ComposeState.signing_repo),
+                         "<span class='label label-warning'>Signing repo</span>")
+
 
 class TestCanWaiveTestResults(base.BaseTestCase):
     """Test the can_waive_test_results() function."""
Repository: fedora-infra/bodhi

Issue:
[L] We need a functioning Greenwave and WaiverDB in the development environment
It is currently very difficult to develop against Greenwave and WaiverDB. There isn't test data in staging, and so we can't test them there, and we obviously don't want to write waivers to the production WaiverDB  during development. We need to have the Vagrant environment provision both of these, and provide an easy way for Bodhi developers to simulate failing tests and set policies.


Discussion:
Could we mock these systems in the development environment ? I am thinking of simple python scripts that would send the expected requests to bodhi ? 

Or maybe this is a silly idea :smile: 
This is Large.
On Fri, 2019-03-01 at 02:24 -0800, Clement Verna wrote:
> Could we mock these systems in the development environment ? I am
> thinking of simple python scripts that would send the expected
> requests to bodhi ?

We do mock them for unit tests, but I estimate that it might actually
be more work to write and maintain a mock than it would be to have
running services.

Should we provide GW and WDB as a docker service(like in integration tests)?

Resolving patch:
diff --git a/devel/docker/settings/greenwave-settings.py b/devel/docker/settings/greenwave-settings.py
new file mode 100644
--- /dev/null
+++ b/devel/docker/settings/greenwave-settings.py
@@ -0,0 +1,15 @@
+HOST = '0.0.0.0'
+PORT = 6545
+DEBUG = False
+POLICIES_DIR = '/etc/greenwave/policies/'
+DIST_GIT_BASE_URL = 'https://src.fedoraproject.org'
+DIST_GIT_URL_TEMPLATE = '{DIST_GIT_BASE_URL}/{pkg_namespace}/{pkg_name}/raw/{rev}/f/gating.yaml'
+KOJI_BASE_URL = 'https://koji.fedoraproject.org/kojihub'
+
+SECRET_KEY = 'this-is-only-for-development'
+WAIVERDB_API_URL = 'http://waiverdb:6544/api/v1.0'
+RESULTSDB_API_URL = 'https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0'
+CORS_URL = '*'
+CACHE = {
+    "backend": "dogpile.cache.memory_pickle",
+}
diff --git a/devel/docker/settings/waiverdb-settings.py b/devel/docker/settings/waiverdb-settings.py
new file mode 100644
--- /dev/null
+++ b/devel/docker/settings/waiverdb-settings.py
@@ -0,0 +1,11 @@
+DATABASE_URI = 'postgresql+psycopg2://waiverdb@wdb:5432/waiverdb'
+RESULTSDB_API_URL = 'https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0'
+SECRET_KEY = 'this-is-only-for-development'
+CORS_URL = '*'
+
+# MESSAGE_BUS_PUBLISH = True
+MESSAGE_BUS_PUBLISH = False
+
+AUTH_METHOD = 'dummy'
+SUPERUSERS = ['bodhi_user']
+PORT = 6544


Test patch:
Repository: fedora-infra/bodhi

Issue:
Support Sourceware bugs in Fedora enhanced markdown
Many key projects reside on sourceware.org including glibc, gdb, binutils, elfutils, libabigail, systemtap etc.

Could you please add markdown support for sourceware.org bugzilla (https://sourceware.org/bugzilla/)?

I suggest a unified markup of SWBZ#XXXX or SW#XXXX for all projects on the main sourceware bugzilla instance.

Likewise gcc compiler bugs are also on sourceware but use a distinct instance (https://gcc.gnu.org/bugzilla/)

I suggest a markup of GCC#XXXX for gcc bugs.

Thank you!


Discussion:

Resolving patch:
diff --git a/bodhi/server/ffmarkdown.py b/bodhi/server/ffmarkdown.py
--- a/bodhi/server/ffmarkdown.py
+++ b/bodhi/server/ffmarkdown.py
@@ -53,7 +53,8 @@ def bug_url(tracker, idx):
 
     Args:
         tracker (basestring): Which bug tracker is being referenced. May be any of 'fedora',
-            'gnome', 'kde', 'mozilla', 'pear', 'perl', 'php', 'python', 'rh', or 'rhbz'.
+            'gcc', 'gnome', 'kde', 'mozilla', 'pear', 'perl', 'php', 'python', 'rh', 'rhbz'
+            or 'sourceware'.
         idx (basestring or int): The bug number.
     Returns:
         basestring: The URL of the given bug.
@@ -61,17 +62,21 @@ def bug_url(tracker, idx):
         KeyError: If the given tracker is not supported by this function.
     """
     try:
-        return {
+        trackers = {
             'fedora': "https://bugzilla.redhat.com/show_bug.cgi?id=%s",
+            'gcc': "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=%s",
             'gnome': "https://bugzilla.gnome.org/show_bug.cgi?id=%s",
             'kde': "https://bugs.kde.org/show_bug.cgi?id=%s",
             'mozilla': "https://bugzilla.mozilla.org/show_bug.cgi?id=%s",
-            'pear': "http://pear.php.net/bugs/bug.php?id=%s",
+            'pear': "https://pear.php.net/bugs/bug.php?id=%s",
             'perl': "https://rt.cpan.org/Public/Bug/Display.html?id=%s",
             'php': "https://bugs.php.net/bug.php?id=%s",
             'python': "https://bugs.python.org/issue%s",
             'rh': "https://bugzilla.redhat.com/show_bug.cgi?id=%s",
-            'rhbz': "https://bugzilla.redhat.com/show_bug.cgi?id=%s"}[tracker.lower()] % idx
+            'rhbz': "https://bugzilla.redhat.com/show_bug.cgi?id=%s",
+            'sourceware': "https://sourceware.org/bugzilla/show_bug.cgi?id=%s"}
+
+        return trackers[tracker.lower()] % idx
 
     except KeyError:
         return None


Test patch:
Repository: fedora-infra/bodhi

Issue:
remove upgradepath from mandatory checks
Currently, `dist.upgradepath` is listed in `site_requirements` in Bodhi. FESCo asked us to drop upgradepath check, because it's no longer important, see https://pagure.io/taskotron/issue/244. Due to that, we stopped executing it. Please remove it from the list of mandatory/important checks, thanks.

Grepping the source code, I see it mentioned in `production.ini` and `bodhi/client/bindings.py`.


Discussion:

Resolving patch:
diff --git a/bodhi/server/config.py b/bodhi/server/config.py
--- a/bodhi/server/config.py
+++ b/bodhi/server/config.py
@@ -493,7 +493,7 @@ class BodhiConfig(dict):
             'value': 'CHANGEME',
             'validator': _validate_secret},
         'site_requirements': {
-            'value': 'dist.rpmdeplint dist.upgradepath',
+            'value': 'dist.rpmdeplint',
             'validator': str},
         'skopeo.cmd': {
             'value': '/usr/bin/skopeo',


Test patch:
Repository: fedora-infra/bodhi

Issue:
Bodhi logs at error if a user tries to push an update they cannot push
If a user tries to push an update that they cannot push, it results in this message being logged at ERROR:

```
2019-06-05 12:38:05,147 ERROR [bodhi.server][Dummy-4] Failed to set the request: This critical path update has not yet been approved for pushing to the stable repository.  It must first reach a karma of 2, consisting of 0 positive karma from proventesters, along with 2 additional karma from the community. Or, it must spend 14 days in testing without any negative feedback Additionally, it must pass automated tests.
```

This should not be logged at error. Perhaps info, or even debug.


Discussion:

Resolving patch:
diff --git a/bodhi/server/services/updates.py b/bodhi/server/services/updates.py
--- a/bodhi/server/services/updates.py
+++ b/bodhi/server/services/updates.py
@@ -201,7 +201,7 @@ def set_request(request):
     try:
         update.set_request(request.db, action, request.user.name)
     except BodhiException as e:
-        log.error("Failed to set the request: %s", e)
+        log.info("Failed to set the request: %s", e)
         request.errors.add('body', 'request', str(e))
     except Exception as e:
         log.exception("Unhandled exception in set_request")


Test patch:
diff --git a/bodhi/tests/server/services/test_updates.py b/bodhi/tests/server/services/test_updates.py
--- a/bodhi/tests/server/services/test_updates.py
+++ b/bodhi/tests/server/services/test_updates.py
@@ -888,8 +888,8 @@ def test_test_gating_status_passed(self):
                 side_effect=BodhiException('BodhiException. oops!'))
     @mock.patch('bodhi.server.services.updates.Update.check_requirements',
                 return_value=(True, "a fake reason"))
-    @mock.patch('bodhi.server.services.updates.log.error')
-    def test_BodhiException_exception(self, log_error, check_requirements, send_request, *args):
+    @mock.patch('bodhi.server.services.updates.log.info')
+    def test_BodhiException_exception(self, log_info, check_requirements, send_request, *args):
         """Ensure that an BodhiException Exception is handled by set_request()."""
         nvr = 'bodhi-2.0-1.fc17'
 
@@ -906,8 +906,8 @@ def test_BodhiException_exception(self, log_error, check_requirements, send_requ
         self.assertEqual(res.json_body['status'], 'error')
         self.assertEqual(res.json_body['errors'][0]['description'],
                          'BodhiException. oops!')
-        log_error.assert_called_once()
-        self.assertEqual("Failed to set the request: %s", log_error.call_args_list[0][0][0])
+        self.assertEqual(log_info.call_count, 2)
+        self.assertEqual("Failed to set the request: %s", log_info.call_args_list[1][0][0])
 
     @mock.patch(**mock_valid_requirements)
     @mock.patch('bodhi.server.services.updates.Update.set_request',
Repository: fedora-infra/bodhi

Issue:
Add ctype to the ComposeComplete schema
Currently the regindexer code that maintains an index of Flatpaks and containers in the Fedora registry looks at the 'ctype' field of a ~mashtask~compose.complete message to know whether the index needs to be rebuilt:

``` python
   match_topic = conf.daemon.topic_prefix + '.' + conf.daemon.environment + '.bodhi.masktask.complete'
   for name, endpoint, topic, raw_msg in fedmsg.tail_messages(topic=match_topic):
        msg = raw_msg['msg']
        if msg.get('ctype') in ('container', 'flatpak'):
            indexer_thread.reindex('Bodhi mash, ctype="%s"' % msg['ctype'])
```

The ctype field is not part of the ComposeCompleteV1 schema - it would be great if it could be added, since I'd like to continue using it when switching to fedora-messaging.

(@bowlofeggs suggested possibly extending the topic - I suppose like `compose.complete.flatpak` - I don't see a reason to go that fancy - there are few compose.complete messages.)


Discussion:

Resolving patch:
diff --git a/bodhi/messages/schemas/compose.py b/bodhi/messages/schemas/compose.py
--- a/bodhi/messages/schemas/compose.py
+++ b/bodhi/messages/schemas/compose.py
@@ -44,6 +44,10 @@ class ComposeCompleteV1(BodhiMessage):
             'success': {
                 'type': 'boolean',
                 'description': 'true if the compose was successful, false otherwise.'
+            },
+            'ctype': {
+                'type': 'string',
+                'description': 'Type of the compose.'
             }
         },
         'required': ['agent', 'repo', 'success'],
@@ -61,6 +65,11 @@ def success(self) -> bool:
         """Return the name of the repository being composed."""
         return self.body.get('success')
 
+    @property
+    def ctype(self) -> str:
+        """Return the compose type."""
+        return self.body.get('ctype')
+
     @property
     def summary(self) -> str:
         """


Test patch:
diff --git a/bodhi/tests/messages/schemas/test_compose.py b/bodhi/tests/messages/schemas/test_compose.py
--- a/bodhi/tests/messages/schemas/test_compose.py
+++ b/bodhi/tests/messages/schemas/test_compose.py
@@ -76,12 +76,14 @@ def test_complete_v1_failed(self):
             'agent': 'mohanboddu',
             'repo': 'test_repo',
             'success': False,
+            'ctype': 'container',
         }
         msg = ComposeCompleteV1(
             body={
                 'agent': 'mohanboddu',
                 'success': False,
                 'repo': 'test_repo',
+                'ctype': 'container',
             }
         )
         check_message(msg, expected)
@@ -98,12 +100,14 @@ def test_complete_v1_success(self):
             'agent': 'mohanboddu',
             'repo': 'test_repo',
             'success': True,
+            'ctype': 'container',
         }
         msg = ComposeCompleteV1(
             body={
                 'agent': 'mohanboddu',
                 'success': True,
                 'repo': 'test_repo',
+                'ctype': 'container',
             }
         )
         check_message(msg, expected)