releng/tickets

Fork 2

icu4j git repository: unable to create temporary object directory #13427

New issue

Closed

opened 2026-07-15 12:55:07 +00:00 by jjames · 9 comments

jjames commented

2026-07-15 12:55:07 +00:00

Member

Describe the issue

I am trying to push a commit to the rawhide branch of the icu4j package repository:

$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 16 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 423 bytes | 423.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
error: remote unpack failed: unable to create temporary object directory
To ssh://pkgs.fedoraproject.org/rpms/icu4j
 ! [remote rejected] rawhide -> rawhide (unpacker error)
error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/icu4j'

I have been able to push commits to other packages, so it is something specific to this particular repository.

When do you need this? (YYYY/MM/DD)

ASAP

When is this no longer needed or useful? (YYYY/MM/DD)

N/A

If we cannot complete this, what is the impact? [Dependencies/Blocker]

The icu4j package cannot be updated.

Checklist

I have checked existing issues for duplicates
I have filled out all the fields above
I have provided relevant links or references (if applicable)

## Describe the issue I am trying to push a commit to the rawhide branch of the icu4j package repository: ``` $ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 16 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 423 bytes | 423.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0) error: remote unpack failed: unable to create temporary object directory To ssh://pkgs.fedoraproject.org/rpms/icu4j ! [remote rejected] rawhide -> rawhide (unpacker error) error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/icu4j' ``` I have been able to push commits to other packages, so it is something specific to this particular repository. ## When do you need this? (YYYY/MM/DD) ASAP ## When is this no longer needed or useful? (YYYY/MM/DD) N/A ## If we cannot complete this, what is the impact? [Dependencies/Blocker] The icu4j package cannot be updated. --- ## Checklist - [x] I have checked existing issues for duplicates - [x] I have filled out all the fields above - [x] I have provided relevant links or references (if applicable)

yselkowitz commented

2026-07-15 14:20:16 +00:00

Member

Did you start with a recent clean checkout of this dist-git repository, or a long-existing one?

If the latter, please be aware that this was one of the repos recreated due to git fsck issues; see #11822 for details. Starting with a fresh checkout may resolve this.

Did you start with a recent clean checkout of this dist-git repository, or a long-existing one? If the latter, please be aware that this was one of the repos recreated due to `git fsck` issues; see #11822 for details. Starting with a fresh checkout may resolve this.

jjames commented

2026-07-15 15:03:15 +00:00

Author

Member

Yes, I saw the announcement about that and checked the repo out again. Just to be sure, I once more checked the repo out again just now. Trying to push a fresh git commit to the repo has the same result as reported above.

jjames commented

2026-07-17 15:43:06 +00:00

Author

Member

I note that there is no F45 mass rebuild commit in that repo, so I assume the mass rebuild script hit the same problem.

jjames referenced this issue

2026-07-17 15:54:42 +00:00

Numerous Packages in Fedora fail git-fsck #11822

kevin added the

labels

2026-07-17 16:33:53 +00:00

kevin added this to the Sprint ( 2026-07-13 to 2026-07-26 ) project

2026-07-17 16:34:01 +00:00

kevin self-assigned this

2026-07-17 16:34:06 +00:00

kevin commented

2026-07-17 16:34:11 +00:00

Owner

I'll try and look at this this morning.

kevin commented

2026-07-17 17:04:12 +00:00

Owner

I think I have them all fixed. Can you try and push and confirm?

jjames commented

2026-07-17 19:03:05 +00:00

Author

Member

Indeed, that worked. Thanks, Kevin!

kevin commented

2026-07-17 19:26:29 +00:00

Owner

Great, and sorry about that.

kevin closed this issue

2026-07-17 19:26:29 +00:00

sgallagh commented

2026-07-22 00:23:22 +00:00

Member

@kevin Sorry to necro-post, but could you give a summary of what went wrong and how it was fixed, in case we hit the same problem in the future?

kevin commented

2026-07-22 00:41:09 +00:00

Owner

So, it's likely more of a bare repo/pagure thing than anything you would hit anywhere else where you would just push to.

Permissions on the bare repos on pkgs01 needed to have dirs with mode 2775 (so packager group has access) and files with mode ( 664 ) so packager group has access. The newly created repos didn't have that... So, it's likely more of a bare repo/pagure thing than anything you would hit anywhere else where you would just push to.