I just tried to submit an update via `fedpkg update` but got a failure via the cli: $ fedpkg update Could not execute update: Could not generate update request: 'anonymous' A copy of the filled in template is saved as bodhi.template.last

On Tue, 2019-05-28 at 17:41 -0400, Dan Čermák wrote: > I just tried to submit an update via `fedpkg update` but got a > failure > via the cli: > $ fedpkg update > Could not execute update: Could not generate update request: > 'anonymous' > A copy of the filled in template is saved as bodhi.template.last > > Nevertheless the update got submitted and is available on Bodhi (it's > this one: > https://bodhi.fedoraproject.org/updates/FEDORA-2019-16433c312e). Hi Dan! I presume you are using a Bodhi 2 or 3 client there? This is a known compatibility issue between the Bodhi 3 client and the Bodhi 4 server: https://bugzilla.redhat.com/show_bug.cgi?id=1714950 There's a FESCo ticket where we are discussing what to do about it. I'm kind of undecided between putting Bodhi 4 into Fedora 29+ (and maybe even EPEL 7, which may be tricky due to dependencies) and making a Bodhi 3.15 that can talk to Bodhi 4 server (downside is that this will require more effort on my part, and I have a lot on my plate ☹). Feel free to voice your opinions on the FESCo ticket!

On Wed, 2019-05-29 at 11:58 -0400, Josh Boyer wrote: > Could you make a container image based on F30 that can be run on > F29/EPEL 7/8? That offers users a way to use the new tool on the OS > of their choice and avoids you having to write new code or bring back > a bunch of dependencies to the Fedora release itself. Yeah anyone could easily do this (just a FROM line [note: it's in Rawhide, not F30] and a RUN dnf install line), but there are also dependencies on bodhi-client in EPEL 7 and F29/30 so it wouldn't fully address the issue. Any end user who wants to work around it could do this though, and I have also provided a Copr[0] that has the new Bodhi client that you can use too. I also considered modularity, but there's currently a stay on adding new packages to the default stream since RPMs can't currently depend on modules (and things do depend on Bodhi). Miro and I have proposed on the FESCo ticket to create a bodhi3-client package and upgrade F29/30 to Bodhi 4. [0] https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi

Greetings! I have just deployed Bodhi 4.0.0 to production: https://bodhi.fedoraproject.org/docs/user/release_notes.html One known issue has been found[0] so far: after creating an update, your browser will be redirected to a URL that does not exist. The update was created, however, and you should receive an e-mail with the URL to it (and can also see it on your user page in Bodhi). Let me know if you find any other problems! [0] https://github.com/fedora-infra/bodhi/issues/3248

Perhaps this is the source of: # /etc/cron.hourly/0yum-hourly.cron Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d1 53d7a3e27ff41946f476af5b4-updateinfo.xml.zck', mode 'rt' at 0x7fa11cc331e0> https://pagure.io/releng/issue/8392

If you're already working on fixing bugs - searching in the web interface also seems to be broken. Entries on an autocompleted result in the "package" section link to a (usually non-existent) user page.

On Wed, May 29, 2019, 18:52 Randy Barlow <bowlofeggs(a)fedoraproject.org&gt; wrote: > > On Wed, 2019-05-29 at 17:51 +0200, Fabio Valentini wrote: > > If you're already working on fixing bugs - searching in the web > > interface also seems to be broken. > > Entries on an autocompleted result in the "package" section link to a > > (usually non-existent) user page. > > That's surprising, and sounds like this issue: > > https://github.com/fedora-infra/bodhi/issues/3040 Yep, that's exactly what happened. However, after deleting the browser cache for the bodhi site and trying again, it now works as expected. Thanks! I guess there was some stale JavaScript in the cache that didn't get reloaded. Fabio