infra/tickets

Fork 0

Push to dist git staging repos is not possible #13076

New issue

Closed

opened 2026-01-22 19:22:31 +00:00 by amedvede · 7 comments

amedvede commented

2026-01-22 19:22:31 +00:00

Description of request

Hey, the problem is probably on the server side. When you try to clone a repo, make changes, and push it, you will get following error:

error: remote unpack failed: unable to create temporary object directory

The reason is probably in the group permissions for directories. Previously, I had an issue that I couldn't create a repository by using fedpkg-stage request-repo. It was throwing an error 500, which does not describe anything. The solution was to change group permissions for rpms/ to xpackager; previously, it was pagure. This group seems to be a new one, because half of dirs has it and half of the others has old one.

### Description of request Hey, the problem is probably on the server side. When you try to clone a repo, make changes, and push it, you will get following error: ``` error: remote unpack failed: unable to create temporary object directory ``` The reason is probably in the group permissions for directories. Previously, I had an issue that I couldn't create a repository by using `fedpkg-stage request-repo`. It was throwing an error 500, which does not describe anything. The solution was to change group permissions for `rpms/` to `xpackager`; previously, it was `pagure`. This group seems to be a new one, because half of dirs has it and half of the others has old one.

james added the

labels

2026-01-22 20:07:00 +00:00

kevin referenced this issue

2026-01-22 23:23:28 +00:00

Request for sysadmin permission #13013

kevin commented

2026-01-22 23:32:17 +00:00

Owner

I think it might be due to pagure user not being in that xpackager group by default.
I adjusted it there and restarted things... can you try another push?

I think it might be due to pagure user not being in that xpackager group by default. I adjusted it there and restarted things... can you try another push?

zlopez commented

2026-01-23 09:08:19 +00:00

Owner

I just tried it on my own fork with fedpkg-stage --user zlopez push and it failed with the same error.

I will check it out.

I just tried it on my own fork with `fedpkg-stage --user zlopez push` and it failed with the same error. I will check it out.

zlopez self-assigned this

2026-01-23 09:08:24 +00:00

zlopez commented

2026-01-23 10:25:20 +00:00

Owner

I did some digging, but I'm not sure what exactly is happening. The problem is that on production it seems that every user is in xpackager (I noticed that the packager group is missing) group, but getent group xpackager only shows xpackager:*:1494358698:xpagure. The same output of getent group xpackager is on staging, but on staging users are not in xpackager group, just packager group.

xpackager isn't IPA group, but only local. So I'm not sure how the group management works on dist-git, but how it is handled is different between staging and production.

EDIT: I didn't find any mention of xpackager group in ansible repo. So it's not part of any playbook. According to ansible, the files in /srv/git/repositories should be owned by packager group.

I did some digging, but I'm not sure what exactly is happening. The problem is that on production it seems that every user is in `xpackager` (I noticed that the `packager` group is missing) group, but `getent group xpackager` only shows `xpackager:*:1494358698:xpagure`. The same output of `getent group xpackager` is on staging, but on staging users are not in `xpackager` group, just packager group. `xpackager` isn't IPA group, but only local. So I'm not sure how the group management works on dist-git, but how it is handled is different between staging and production. EDIT: I didn't find any mention of `xpackager` group in ansible repo. So it's not part of any playbook. According to ansible, the files in `/srv/git/repositories` should be owned by `packager` group.

zlopez commented

2026-01-26 08:58:03 +00:00

Owner

Just tested it out, adding my user to xpackager group solved the issue.

$ fedpkg-stage -vvv --user zlopez retire "test purpose"                                                                                                                      po 26. ledna 2026, 09:56:32
Creating repo object from /var/home/mkonecny/work/rpms/python3.666
Running: git rm -rf .
rm 'README.md'
Running: git add /var/home/mkonecny/work/rpms/python3.666/dead.package
Running: git commit -m test purpose -a
[rawhide e91a271] test purpose
 2 files changed, 1 insertion(+), 3 deletions(-)
 delete mode 100644 README.md
 create mode 100644 dead.package
Running: git -c credential.helper=/usr/bin/fedpkg-stage gitcred -c credential.useHttpPath=true push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Writing objects: 100% (3/3), 262 bytes | 262.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Protected namespaces: ['rpms', 'modules', 'container']
remote: Blocking unspecified refs: False
remote: Blacklists: [re.compile('refs/heads/c[0-9]+.*')]
remote: User: User: 2651 - name zlopez
remote: User groups: {'packager', 'sysadmin-main'}
remote: Committer: True
remote: SIG memberships: set()
remote: RCM: False
remote: By-pass PR-only: False
remote: Committer push
remote: Protected namespaces: ['rpms', 'modules', 'container']
remote: Blocking unspecified refs: False
remote: Blacklists: [re.compile('refs/heads/c[0-9]+.*')]
remote: User: User: 2651 - name zlopez
remote: User groups: {'sysadmin-main', 'packager'}
remote: Committer: True
remote: SIG memberships: set()
remote: RCM: False
remote: By-pass PR-only: False
remote: Committer push
remote: Sending to redis to log activity and send commit notification emails
remote: * Publishing information for 1 commits
remote:   - to fedora-message
remote: 2026-01-26 08:56:46,402 [WARNING] pagure.lib.notify: pagure is about to send a message that has no schemas: pagure.git.receive
To ssh://pkgs.stg.fedoraproject.org/forks/zlopez/rpms/python3.666.git
   7bdcdfb..e91a271  rawhide -> rawhide
To disable monitoring of the (retired) repository use manually the separate command: 'fedpkg-stage disable-monitoring'

Just tested it out, adding my user to `xpackager` group solved the issue. ``` $ fedpkg-stage -vvv --user zlopez retire "test purpose" po 26. ledna 2026, 09:56:32 Creating repo object from /var/home/mkonecny/work/rpms/python3.666 Running: git rm -rf . rm 'README.md' Running: git add /var/home/mkonecny/work/rpms/python3.666/dead.package Running: git commit -m test purpose -a [rawhide e91a271] test purpose 2 files changed, 1 insertion(+), 3 deletions(-) delete mode 100644 README.md create mode 100644 dead.package Running: git -c credential.helper=/usr/bin/fedpkg-stage gitcred -c credential.useHttpPath=true push Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Writing objects: 100% (3/3), 262 bytes | 262.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) remote: Protected namespaces: ['rpms', 'modules', 'container'] remote: Blocking unspecified refs: False remote: Blacklists: [re.compile('refs/heads/c[0-9]+.*')] remote: User: User: 2651 - name zlopez remote: User groups: {'packager', 'sysadmin-main'} remote: Committer: True remote: SIG memberships: set() remote: RCM: False remote: By-pass PR-only: False remote: Committer push remote: Protected namespaces: ['rpms', 'modules', 'container'] remote: Blocking unspecified refs: False remote: Blacklists: [re.compile('refs/heads/c[0-9]+.*')] remote: User: User: 2651 - name zlopez remote: User groups: {'sysadmin-main', 'packager'} remote: Committer: True remote: SIG memberships: set() remote: RCM: False remote: By-pass PR-only: False remote: Committer push remote: Sending to redis to log activity and send commit notification emails remote: * Publishing information for 1 commits remote: - to fedora-message remote: 2026-01-26 08:56:46,402 [WARNING] pagure.lib.notify: pagure is about to send a message that has no schemas: pagure.git.receive To ssh://pkgs.stg.fedoraproject.org/forks/zlopez/rpms/python3.666.git 7bdcdfb..e91a271 rawhide -> rawhide To disable monitoring of the (retired) repository use manually the separate command: 'fedpkg-stage disable-monitoring' ```

zlopez added

and removed

labels

2026-01-26 09:17:52 +00:00

amedvede referenced this issue from releng/tickets

2026-01-26 14:51:51 +00:00

Test fedpkg request-unretirement functionality #13163

kevin commented

2026-01-27 17:20:32 +00:00

Owner

ok. I think I see the problem.

On pkgs01.stg /etc/group has:
xpackager:*:1494358698:xpagure,git,zlopez

but that is the production gid.
In staging it should be 162801012

I have changed it now.
I think we now need to chgrp -R xpackager /srv/git/repositories

Does that sound right to everyone? (I have not yet done this)

ok. I think I see the problem. On pkgs01.stg /etc/group has: xpackager:*:1494358698:xpagure,git,zlopez but that is the _production_ gid. In staging it should be 162801012 I have changed it now. I think we now need to chgrp -R xpackager /srv/git/repositories Does that sound right to everyone? (I have not yet done this)

👍 1

kevin referenced this issue

2026-01-27 23:35:30 +00:00

src.stg misbehaving #13050

zlopez commented

2026-01-28 10:29:13 +00:00

Owner

I was surprised that the UID is same on staging and production, but didn't look into it more. And git and my user were just added when I was testing things.

I thing everything is already owned by xpackager group in /srv/git/repositories on staging, but I don't have anything against running it again recursively.

I was surprised that the UID is same on staging and production, but didn't look into it more. And `git` and my user were just added when I was testing things. I thing everything is already owned by `xpackager` group in `/srv/git/repositories` on staging, but I don't have anything against running it again recursively.

kevin added this to the Sprint ( 2026-01-26 to 2026-02-08 ) project

2026-01-28 19:26:58 +00:00

kevin self-assigned this

2026-01-28 19:27:10 +00:00

kevin commented

2026-01-28 19:29:36 +00:00

Owner

I have now run this. (well, it's still running, will take a bit).

I think this issue is solved, so I am going to close it.

Please feel free to reopen if there's anything further to do.

I have now run this. (well, it's still running, will take a bit). I think this issue is solved, so I am going to close it. Please feel free to reopen if there's anything further to do.

kevin closed this issue

2026-01-28 19:29:37 +00:00