<dustymabe>
also - we're still blocked for ppc64le - so remove that from the list of arches to build when you start the builds
<jlebon>
dustymabe: easiest is to just re-register all hooks. that'll update github with whatever the shared secret is.
<dustymabe>
jlebon: i.e. go into the web interface and update the secret there?
<dustymabe>
GH web interface for each repo
<jlebon>
dustymabe: no, go to the jenkins main config page, expand the GH section, and click the button that says something like "Re-register all hooks"
<dustymabe>
I see a button for 'Manage hooks' - but nothing that says "Re-register all hooks"
<jlebon>
dustymabe: still investigating. the webhook secret is correct in GH, but the plugin is still not happy with the hash
<gursewak>
will do
<dustymabe>
jlebon: yeah - I was thinking maybe I included a newline that shouldn't be there or something - but If I look at the instructions for creating the secret it looks like it would be right
<dustymabe>
I could try creating the secret without the newline
<dustymabe>
I think the test itself has some sort of opt out mechanism - I think he's saying we should update that and revisit it later
<dustymabe>
the *only* problem I see with that approach is we don't have some sort of "snooze" mechanism to remind us to actually come back to it
<travier[m]>
Commented on GitHub with the link
misuto has quit [Remote host closed the connection]
misuto has joined #fedora-coreos
<travier[m]>
Agree that we would need to come back to it but it's not important enough for now
<dustymabe>
travier[m]: it would be good (even if we add this to some allowlist) to go ahead and file a BZ so we can discuss with the maintainers the issue (assuming it is an issue that the maintainers will see as an issue)
<dustymabe>
can you help gursewak do that write-up?
<travier[m]>
Sure, suggested indeed on github that we file a bug
<dustymabe>
👍
<travier[m]>
Feel free to post a draft in the comment and ping me again and I'll review
<travier[m]>
gursewak: ^^
paragan has quit [Quit: Leaving]
jpn has quit [Ping timeout: 252 seconds]
<dustymabe>
marmijo: the next and testing PRs look good
<dustymabe>
those are ready to merge and start builds
<guesswhat>
hey, question, how can I set systemd dependecny for podman.socket ? is require=podman.service correct way? or will be podman.service triggered multple times via socket ?
<guesswhat>
tldr: i am mounting disk to /var/lib/containers a want to be sure that podman would be ready after this operation via dependecy
<dustymabe>
guesswhat: just set `podman.socket` to enabled ?
<guesswhat>
dustymabe not sure if I follow, lets say that i have three services ( makefs, mount, and container ) , but container has podman dependency, but podman has dependency on makefs and mount ( /var/lib/containers fs path )
<dustymabe>
guesswhat: ok - where does `socket` come into play?
<guesswhat>
oh, sorry, container app has socket mounted.. , its actually creating rootless containers as its business logic
<dustymabe>
so container needs the socket to be created before it can start?
<dustymabe>
container service*
<dustymabe>
Maybe `Requires=podman.service podman.socket` and also `After=podman.service podman.socket`