#6240 Unable to push to stable branches for new packages
Closed: Fixed Opened by ralph.

Packagers can push to the master branch of newly created repos.

But if they also request a f26 branch, they can push there.

  • The request processing admin tool creates the branch in PDC. Good.
  • Pagure is tooled to query PDC to allow the branch in the acl config.
  • However, pagure doesn't get triggered to rebuild the config, so it never takes effect.

Having an admin-protected api endpoint to trigger a task like this would be ideal.


Metadata Update from @pingou:
- Issue tagged with: src.fp.o

See also https://pagure.io/fedrepo_req/issue/56

Metadata Update from @ralph:
- Issue untagged with: src.fp.o

See also https://pagure.io/pagure/issue/2513

Metadata Update from @pingou:
- Issue tagged with: src.fp.o

Can I request a manual configuration update for one repository (rpms/syncthing) until this works automatically?
The requested f25 and f26 branches were approved two days ago, but I still can't push those branches to git (they get rejected by the remote) - and I'd really like to be finally able to push this package to fedora.

Didn't someone test a process like that before pagure went into beta? Why should we packagers find such common use cases to fail? IMHO that should have been detected not later as in alpha tests without an half productive instance.
PkgDB was put into readonly mode, so packagers are enforced to try their work with still heavily b0rken pagure. It's now delaying a lot of productive work and wasting time in finding general pagure bugs.
As you see, I'm really disappointed about this behaviour to enforce pagure over all.

Didn't someone test a process like that before pagure went into beta?

We did, did you?

Can I request a manual configuration update for one repository (rpms/syncthing) until this works automatically?

I have one currently running will start your right after :)

Can I request a manual configuration update for one repository (rpms/syncthing) until this works automatically?

It's running :)

Thanks! I was able to push the two branches. koji builds still fail, but I guess that's a different issue (package syncthing not in list for tag f26-updates-candidate).

@pingou @ralph could someone please update rpms/PyDrive so I can go ahead and build that package for f26 and epel7? Thank you

@nb and @decathorpe I have manually synced your package branches in koji, so you should be able to build them.

The underlying problem still exists, but it shouldn't block those 2 packages while we debug.

Didn't someone test a process like that before pagure went into beta?

We did, did you?

Well, I did and stumpled upon all the severe issues reported here, too. Please can someone of you guys answer my question with at least one good reason why PkgDB was enforced to be read-only in such an early state of the new pagure with untested/not-implemented but important functionalities?

Well, I did and stumpled upon all the severe issues reported here, too. Please can someone of you guys answer my question with at least one good reason why PkgDB was enforced to be read-only in such an early state of the new pagure with untested/not-implemented but important functionalities?

We did test as best we could, but its impossible to know everything is correct without a bunch of real world testing with real world data. We have run into bugs, and we are trying to fix them as quickly as we can. We have been talking about this change for months, so if there was something you saw that was not implemented it would have been nice to tell us. The production setup is a great deal larger than our test env (simply because we don't have resources to make it exactly the same), so issues will show up with scaling to production.

@pingou @kevin would I be able to request a manual update of rpms/clustersos as well so I can build for f26? If I need to wait for this issue to be resolved I completely understand.

@turboturtle manual update running :)

@pingou Could you please update also f26 for python-cloudpickle? Thanks a lot!

@pingou Please also fix f26 and f25 for cld2
Thank you very much

Current situation:

git checkout -b f26
git push --set-upstream origin f26
Total 0 (delta 0), reused 0 (delta 0)
remote: FATAL: C refs/heads/f26 rpms/cld2 c72578 DENIED by refs/heads/f[0-9][0-9]
remote: error: hook declined to update refs/heads/f26
To ssh://pkgs.fedoraproject.org/rpms/cld2
! [remote rejected] f26 -> f26 (hook declined)
error: failed to push some refs to 'ssh://c72578@pkgs.fedoraproject.org/rpms/cld2'

git checkout -b f25
git push --set-upstream origin f25
Total 0 (delta 0), reused 0 (delta 0)
remote: FATAL: C refs/heads/f25 rpms/cld2 c72578 DENIED by refs/heads/f[0-9][0-9]
remote: error: hook declined to update refs/heads/f25
To ssh://pkgs.fedoraproject.org/rpms/cld2
! [remote rejected] f25 -> f25 (hook declined)
error: failed to push some refs to 'ssh://c72578@pkgs.fedoraproject.org/rpms/cld2'

  • rpms/cld2 done
  • rpms/python-cloudpickle done
  • rpms/nuvola-app-mixcloud running

Thanks @pingou! Now I can push but I cannot build.

BuildError: package python-cloudpickle not in list for tag f26-updates-candidate

Is it somehow related to this issue or I found another one?

It's not a new one, but it's not related to dist-git. I believe there is a cron job fixing those and it can be also manually run but I don't know how to do it myself

OK, I think we have a solution in place which should make the package list sync to koji much quicker. I'm doing another run of the mega (slow) job now that should get us back inline. We have a new fedmsg-listener that syncs single packages when their requests are processed. Let us know if that fails.

I think we got everything in place and running fine now.

Please re-open if you think this is not working as expected.

Thanks :)

Metadata Update from @pingou:
- Issue close_status updated to: Fixed

It looks like one of my packages fell through the cracks ...
I can't push f25, f26, and f27 branches to rpms/syncthing-inotify.
These branches were approved and added to PDC more than 2 hours ago.

Metadata