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

Issue:
Sort the builds on the update page alphabetically
It would be nice if the list of builds on the update page's Builds tab were sorted alphabetically.


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
@@ -1119,7 +1119,8 @@ class Update(Base):
     # One-to-many relationships
     comments = relationship('Comment', backref=backref('update', lazy='joined'), lazy='joined',
                             order_by='Comment.timestamp')
-    builds = relationship('Build', backref=backref('update', lazy='joined'), lazy='joined')
+    builds = relationship('Build', backref=backref('update', lazy='joined'), lazy='joined',
+                          order_by='Build.nvr')
 
     # Many-to-many relationships
     bugs = relationship('Bug', secondary=update_bug_table, backref='updates')


Test patch:
diff --git a/bodhi/tests/server/test_push.py b/bodhi/tests/server/test_push.py
--- a/bodhi/tests/server/test_push.py
+++ b/bodhi/tests/server/test_push.py
@@ -468,8 +468,8 @@ def test_locked_updates_not_in_a_push(self, load, glob, publish, mock_file, mock
         glob.assert_called_once_with('/mnt/koji/mash/updates/MASHING-*')
         publish.assert_called_once_with(
             topic='masher.start',
-            msg={'updates': ['python-nose-1.3.7-11.fc17', 'python-paste-deploy-1.5.2-8.fc17',
-                             'ejabberd-16.09-4.fc17'],
+            msg={'updates': ['ejabberd-16.09-4.fc17', 'python-nose-1.3.7-11.fc17',
+                             'python-paste-deploy-1.5.2-8.fc17'],
                  'resume': False, 'agent': 'bowlofeggs'},
             force=True)
         mock_file.assert_called_once_with('/mnt/koji/mash/updates/MASHING-f17-updates')
Repository: fedora-infra/bodhi

Issue:
bodhi.server.util conditionally imports rpm
I don't see a reason for ```bodhi.server.util``` to conditionally import rpm, as opposed to hard depending on it. We should investigate why it is this way, and make it a hard dependency if it makes sense. If this change is made, release notes will need to be written as well.


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
@@ -36,16 +36,12 @@
 import libravatar
 import markdown
 import requests
+import rpm
 
 from bodhi.server import log, buildsys, Session
 from bodhi.server.config import config
 from bodhi.server.exceptions import RepodataException
 
-try:
-    import rpm
-except ImportError:
-    log.warning("Could not import 'rpm'")
-
 
 _ = TranslationStringFactory('bodhi')
 


Test patch:
Repository: fedora-infra/bodhi

Issue:
comment(email=True) does not work
See the docstring for `comment(email=)`:

```
    def comment(self, update, comment, karma=0, email=None):
        """ Add a comment to an update.

        :arg update: The title of the update comment on.
        :arg comment: The text of the comment.
        :kwarg karma: The karma of this comment (-1, 0, 1)
        :kwarg email: Whether or not to trigger email notifications

        """
```

If I call `bodhi_client.comment(bodhi_update['title'], comment, karma)`, everything works, comment is added. But if I call `bodhi_client.comment(bodhi_update['title'], comment, karma, email=True)`, I get `BodhiClientException: Invalid email address`.

However, it is not supposed to be an email address, it is supposed to be a boolean flag.

python-fedora 0.5.5



Discussion:
Ha!  Yeah, the docstring must just be wrong.  That `email` field is there (I think) to allow anonymous comments.

In that case is it still possible to decide whether to send out emails for the submitted comment or not? That's how it used to work in Bodhi1 API (the `email` field was a boolean flag). It's not a critical functionality for us (we want to deprecate taskotron comments soon), but if it is still available in some form, we would make use of it.

Oh, and if the feature is no longer available, what is the current behavior? Send emails for every comment? Or has it all moved to FMN already?

After talking to Luke yesterday, the `email` attribute now has a different meaning than in Bodhi1 (not sure if he wants to revert it or not), and every submitted comment should trigger an email (maybe even 2, one direct and one through FMN). Either way, it should be OK for taskotron to simply submit comments without using `email=` and the maintainers should get notified.

@ralphbean is right, if you supply an email address here, the comment is marked as anon:

https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/services/comments.py#L213

i'll make a quick patch to fix the docstring

Resolving patch:
diff --git a/bodhi/client/bindings.py b/bodhi/client/bindings.py
--- a/bodhi/client/bindings.py
+++ b/bodhi/client/bindings.py
@@ -289,7 +289,8 @@ def comment(self, update, comment, karma=0, email=None):
         :arg update: The title of the update comment on.
         :arg comment: The text of the comment.
         :kwarg karma: The karma of this comment (-1, 0, 1)
-        :kwarg email: Whether or not to trigger email notifications
+        :kwarg email: Email address for an anonymous user. if an email address is
+            supplied here, the comment is added as anonymous (i.e. not a logged in user)
 
         """
         return self.send_request(


Test patch:
Repository: fedora-infra/bodhi

Issue:
bodhi.server.util.taskotron_results doesn't use a timeout on its call to requests.get()
bodhi.server.util.taskotron_results should use a timeout on its call to requests.get() so that it won't hang indefinitely if there are issues communicating with resultsdb. 60 seconds is probably reasonable.


Discussion:
Hello @bowlofeggs !

I would like to work on this issue, can you please assign it to me. Thanks!
Hello @rimshaakhan,

I don't think GitHub allows assigning issues to users who are not in the fedora-infra group, but you are certainly welcome to work on this issue (you don't have to be officially assigned to an issue to work on it). Just make sure you end your commit message with a line that says "fixes #1597" when you send your pull request. Thanks!

Resolving patch:
diff --git a/bodhi/server/util.py b/bodhi/server/util.py
--- a/bodhi/server/util.py
+++ b/bodhi/server/util.py
@@ -677,7 +677,7 @@ def taskotron_results(settings, entity='results/latest', max_queries=10, **kwarg
     try:
         while data and url:
             log.debug("Grabbing %r" % url)
-            response = requests.get(url)
+            response = requests.get(url, timeout=60)
             if response.status_code != 200:
                 raise IOError("status code was %r" % response.status_code)
             json = response.json()


Test patch:
diff --git a/bodhi/tests/server/test_utils.py b/bodhi/tests/server/test_utils.py
--- a/bodhi/tests/server/test_utils.py
+++ b/bodhi/tests/server/test_utils.py
@@ -521,6 +521,7 @@ def test_taskotron_results_paging(self, mock_get):
         self.assertEqual(mock_get.return_value.json.call_count, 2)
         self.assertEqual(mock_get.call_count, 2)
         self.assertEqual(mock_get.call_args[0][0], 'url2')
+        self.assertEqual(mock_get.call_args[1]['timeout'], 60)
 
     @mock.patch('bodhi.server.util.requests.get')
     @mock.patch('bodhi.server.util.log.debug')
Repository: fedora-infra/bodhi

Issue:
Don't disable autopush when the update is already requested for stable
@ignatenkobrain reported today that [an update](https://bodhi.fedoraproject.org/updates/FEDORA-2017-92e5a01da8) didn't have the push to stable button, even though Bodhi had commented on the update to say "Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe." It turned out that the update had already been submitted for stable by reaching the karma threshold earlier. The comment from Bodhi that autopush was being disabled was confusing and misleading. Bodhi should not disable autopush if the update is already requested for stable, or if the update is already stable.


Discussion:
@bowlofeggs  I would like to solve this bug as I am beginner and you've tagged it as easyfix. Could you help me where to get started ?


Resolving patch:
diff --git a/bodhi/server/models.py b/bodhi/server/models.py
--- a/bodhi/server/models.py
+++ b/bodhi/server/models.py
@@ -2361,7 +2361,8 @@ def check_karma_thresholds(self, db, agent):
         if self.status not in (UpdateStatus.testing, UpdateStatus.pending):
             return
         # If an update receives negative karma disable autopush
-        if self.autokarma and self._composite_karma[1] != 0 and self.status is UpdateStatus.testing:
+        if self.autokarma and self._composite_karma[1] != 0 and self.status is \
+                UpdateStatus.testing and self.request is not UpdateRequest.stable:
             log.info("Disabling Auto Push since the update has received negative karma")
             self.autokarma = False
             text = config.get('disable_automatic_push_to_stable')


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
@@ -2614,7 +2614,7 @@ def test_obsolete_if_unstable_with_autopush_enabled_when_testing(self, publish,
         """
         Send update to obsolete state if it reaches unstable karma threshold on
         testing state where request is stable when Autopush is enabled. Make sure that the
-        autopush is disabled and the update does not go to stable state.
+        autopush remains enabled and the update does not go to stable state.
         """
         nvr = u'bodhi-2.0.0-2.fc17'
         args = self.get_update(nvr)
@@ -2641,7 +2641,7 @@ def test_obsolete_if_unstable_with_autopush_enabled_when_testing(self, publish,
         up = self.db.query(Update).filter_by(title=nvr).one()
 
         self.assertEquals(up.karma, -2)
-        self.assertEquals(up.autokarma, False)
+        self.assertEquals(up.autokarma, True)
         self.assertEquals(up.status, UpdateStatus.obsolete)
         self.assertEquals(up.request, None)
Repository: fedora-infra/bodhi

Issue:
symlink check is not valid
https://github.com/fedora-infra/bodhi/blob/33d1e733d88bc891e00bf9f0e09d471360253ab1/bodhi/server/consumers/masher.py#L723-L729

The code is checking `.rpm` files under `mash_path, arches[0]` but you can see from [this example](https://kojipkgs.fedoraproject.org/mash//updates/f26-updates-170804.1348/f26-updates/x86_64/) that no rpm files exist. They are just directories. 




Discussion:

Resolving patch:
diff --git a/bodhi/server/consumers/masher.py b/bodhi/server/consumers/masher.py
--- a/bodhi/server/consumers/masher.py
+++ b/bodhi/server/consumers/masher.py
@@ -704,7 +704,6 @@ def generate_updateinfo(self):
     def sanity_check_repo(self):
         """Sanity check our repo.
 
-            - make sure we didn't compose a repo full of symlinks
             - sanity check our repodata
         """
         mash_path = os.path.join(self.path, self.id)
@@ -720,14 +719,6 @@ def sanity_check_repo(self):
                 self.log.error("Repodata sanity check failed!\n%s" % str(e))
                 raise
 
-        # make sure that mash didn't symlink our packages
-        for pkg in os.listdir(os.path.join(mash_path, arches[0])):
-            if pkg.endswith('.rpm'):
-                if os.path.islink(os.path.join(mash_path, arches[0], pkg)):
-                    self.log.error("Mashed repository full of symlinks!")
-                    raise Exception
-                break
-
         return True
 
     def stage_repo(self):


Test patch:
Repository: fedora-infra/bodhi

Issue:
Bodhi is missing a uniqueness constraint on packages(name, type) due to a migration error
@tyll and I have noticed that Bodhi is missing a compound uniqueness constraint on the packages table for the ```name``` and ```type``` fields, which is apparent when you ask alembic to autogenerate a migration.

I looked into the history and I think I found out what happened. It seems that there was a migration added to create this field in f404e248872e6a99ef5dc703f496dd729780f3b2. However, the field's type was changed in cb8b2ab4d14c8ce2e269843162219811216990ef and when I did that I didn't noticed that I had effectively dropped the constraint when I deleted the type column.

Thus, we simply need a migration to add it back.


Discussion:

Resolving patch:
diff --git a/bodhi/server/migrations/versions/74cfbc6116ad_add_packages_type_constraint.py b/bodhi/server/migrations/versions/74cfbc6116ad_add_packages_type_constraint.py
new file mode 100644
--- /dev/null
+++ b/bodhi/server/migrations/versions/74cfbc6116ad_add_packages_type_constraint.py
@@ -0,0 +1,40 @@
+# Copyright (c) 2017 Red Hat, Inc.
+#
+# This file is part of Bodhi.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+"""
+Add packages type constraint.
+
+Revision ID: 74cfbc6116ad
+Revises: 95ce24bed77a
+Create Date: 2017-11-21 19:52:30.058663
+"""
+from alembic import op
+
+
+# revision identifiers, used by Alembic.
+revision = '74cfbc6116ad'
+down_revision = '95ce24bed77a'
+
+
+def upgrade():
+    """Create a uniqueness constraint on packages.{name,type}."""
+    op.create_unique_constraint('packages_name_and_type_key', 'packages', ['name', 'type'])
+
+
+def downgrade():
+    """Drop the uniqueness constraint on packages.{name,type}."""
+    op.drop_constraint('packages_name_and_type_key', 'packages', type_='unique')


Test patch:
Repository: fedora-infra/bodhi

Issue:
Bodhi's help text gives incorrect example for multi-build updates
Petr Pisar [reported](https://bugzilla.redhat.com/show_bug.cgi?id=1515766) this issue originally:

> please fix this example in the "bodhi updates new --help" output:
> 
> $ bodhi updates new --help
> Usage: bodhi updates new [OPTIONS] BUILDS
> 
>   Create a new update.
> 
>   BUILDS: a comma separated list of Builds to be added to the update (e.g.
>   0ad-0.0.21-4.fc26, 2ping-3.2.1-4.fc26)
> 
> 
> The last line should be:
> 
>   0ad-0.0.21-4.fc26,2ping-3.2.1-4.fc26)


Discussion:

Resolving patch:
diff --git a/bodhi/client/__init__.py b/bodhi/client/__init__.py
--- a/bodhi/client/__init__.py
+++ b/bodhi/client/__init__.py
@@ -183,7 +183,7 @@ def new(user, password, url, **kwargs):
     Create a new update.
 
     BUILDS: a comma separated list of Builds to be added to the update
-    (e.g. 0ad-0.0.21-4.fc26, 2ping-3.2.1-4.fc26)
+    (e.g. 0ad-0.0.21-4.fc26,2ping-3.2.1-4.fc26)
     """
 
     # Developer Docs


Test patch:
Repository: fedora-infra/bodhi

Issue:
The recently added backref=updates on the Update.release relationship slows front page
The front page of Bodhi doesn't load within several minutes on the develop branch. I've traced it back to the recently added [```backref='updates'``` line](https://github.com/fedora-infra/bodhi/blob/5371bbd18611f85bb3767ba8968401b5f48f5e2f/bodhi/server/models.py#L1522):

```
release = relationship('Release', lazy='joined', backref='updates')
```

Removing the backref gets the page to load quickly again.


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
@@ -1519,7 +1519,7 @@ class Update(Base):
 
     # One-to-one relationships
     release_id = Column(Integer, ForeignKey('releases.id'), nullable=False)
-    release = relationship('Release', lazy='joined', backref='updates')
+    release = relationship('Release', lazy='joined')
 
     # One-to-many relationships
     comments = relationship('Comment', backref=backref('update', lazy='joined'), lazy='joined',
@@ -1577,10 +1577,9 @@ def validate_release(self, key, release):
                 update.
         """
         if release and self.content_type is not None:
-            if len(release.updates):
-                u = release.updates[0]
-                if u.content_type and u.content_type != self.content_type:
-                    raise ValueError(u'A release must contain updates of the same type.')
+            u = Update.query.filter(Update.release_id == release.id, Update.id != self.id).first()
+            if u and u.content_type and u.content_type != self.content_type:
+                raise ValueError(u'A release must contain updates of the same type.')
         return release
 
     @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
@@ -2544,9 +2544,12 @@ def test_validate_release_failure(self):
             builds=[build], user=user,
             status=UpdateStatus.testing,
             request=UpdateRequest.stable,
-            notes=u'Useful details!', release=release,
+            type=UpdateType.enhancement,
+            notes=u'Useful details!',
             test_gating_status=TestGatingStatus.passed)
+        update.release = release
         self.db.add(update)
+        self.db.flush()
 
         # We should not be allowed to add our RPM Update to the Module release.
         with self.assertRaises(ValueError) as exc:
Repository: fedora-infra/bodhi

Issue:
The Release has a uniqueness constraint on branch name
While working on #2028 today, I discovered that I needed to use the container's release's branch in order to know the prefix on the container's name in the registries (i.e., if I am composing the s2i-core container, it's actually called f27/s2i-core in the registry, and I need to know that f27 prefix). Since containers have their own koji tags separately of the RPM koji tags, they will need to have their own release in Bodhi. This causes a problem, because I need the F27 container release to use "f27" for the branch field, but the F27 RPM release is already using "f27" on its branch field and there is a uniqueness constraint.

I grepped the code for "branch" and I do not believe this uniqueness constraint serves a purpose, so I think we can simple drop it.


Discussion:

Resolving patch:
diff --git a/bodhi/server/migrations/versions/adee0d22d09f_drop_the_uniqueness_constraint_on_.py b/bodhi/server/migrations/versions/adee0d22d09f_drop_the_uniqueness_constraint_on_.py
new file mode 100644
--- /dev/null
+++ b/bodhi/server/migrations/versions/adee0d22d09f_drop_the_uniqueness_constraint_on_.py
@@ -0,0 +1,40 @@
+# Copyright (c) 2018 Red Hat, Inc.
+#
+# This file is part of Bodhi.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+"""
+Drop the uniqueness constraint on releases.branch.
+
+Revision ID: adee0d22d09f
+Revises: 2616c86d8ac6
+Create Date: 2018-03-13 20:55:03.345503
+"""
+from alembic import op
+
+
+# revision identifiers, used by Alembic.
+revision = 'adee0d22d09f'
+down_revision = '2616c86d8ac6'
+
+
+def upgrade():
+    """Drop the uniqueness constraint on releases.branch."""
+    op.drop_constraint(u'releases_branch_key', 'releases', type_='unique')
+
+
+def downgrade():
+    """Recreate the uniqueness constraint on releases.branch."""
+    op.create_unique_constraint(u'releases_branch_key', 'releases', ['branch'])
diff --git a/bodhi/server/models.py b/bodhi/server/models.py
--- a/bodhi/server/models.py
+++ b/bodhi/server/models.py
@@ -814,7 +814,7 @@ class Release(Base):
     long_name = Column(Unicode(25), unique=True, nullable=False)
     version = Column(Unicode(5), nullable=False)
     id_prefix = Column(Unicode(25), nullable=False)
-    branch = Column(Unicode(10), unique=True, nullable=False)
+    branch = Column(Unicode(10), nullable=False)
 
     dist_tag = Column(Unicode(20), nullable=False)
     stable_tag = Column(UnicodeText, nullable=False)


Test patch:
Repository: fedora-infra/bodhi

Issue:
What is "pending" status?
Can Bodhi interface explain what is pending? What can I do with package in pending state? What states are available to find the state I need? Why the current state like this and what is it waiting?

![image](https://user-images.githubusercontent.com/8781107/36199620-1fdfbb96-118b-11e8-8dc9-e5c0e3c48b2e.png)

In particular, I am trying to know when I can test https://bodhi.fedoraproject.org/updates/FEDORA-2018-54c7a5b01b from `updates-testing` repository.



Discussion:
@abitrolly There is documentation on Bodhi's states that will be distributed with the upcoming 3.3.0 release. A beta for that version is deployed to staging, so you can see those docs there:

https://bodhi.stg.fedoraproject.org/docs/user/update_states.html

Updates are available in the ```updates-testing``` repository once they reach the ```testing``` state (not the ```testing``` request. It is possible to download the RPMs from Koji if you want to get them sooner. You can see links to the Koji builds on the builds tab in Bodhi.

All that said, perhaps we could add mouseovers to the status to make its meaning more discoverable.
Mouseovers would be great as well as more detailed Pending status. https://bodhi.stg.fedoraproject.org/docs/user/update_states.html#pending lists additional checks to be performed, and it would be nice to get them visualized or highlighted in description.

Resolving patch:
diff --git a/bodhi/server/util.py b/bodhi/server/util.py
--- a/bodhi/server/util.py
+++ b/bodhi/server/util.py
@@ -516,7 +516,18 @@ def status2html(context, status):
         'obsolete': 'default',
         'processing': 'info',
     }[status]
-    return "<span class='label label-%s'>%s</span>" % (cls, status)
+    status_desc = {
+        'pending': 'The update has not yet been pushed to the testing or stable repositories.',
+        'testing': 'The package is in the testing repository for people to test.',
+        'stable': 'The package has been released to the stable repository.',
+        'unpushed': 'The update has been removed from testing.',
+        'obsolete': 'The package has been obsoleted by a different update.',
+        'processing': 'Unused.',
+    }[status]
+
+    return ("<span class='text-muted' data-toggle='tooltip' title='%s'>" % (status_desc) +
+            "<span class='label label-%s'>%s</span>" % (cls, status) +
+            "</span>")
 
 
 def test_gating_status2html(context, status, reason=None):


Test patch: