Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 906706 - sys-apps/portage - automatic garbage collection fails when syncing gentoo.git
Summary: sys-apps/portage - automatic garbage collection fails when syncing gentoo.git
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - External Interaction (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-18 21:15 UTC by Toralf Förster
Modified: 2023-12-14 16:55 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Toralf Förster gentoo-dev 2023-05-18 21:15:49 UTC
From time to time I do get:


p14s ~ # emaint sync -a
>>> Syncing repository 'gentoo' into '/var/db/repos/gentoo'...
Auto packing the repository for optimum performance.
See "git help gc" for manual housekeeping.
Enumerating objects: 133141, done.
Nothing new to pack.
warning: There are too many unreachable loose objects; run 'git prune' to remove them.
/usr/bin/git fetch origin --depth 1
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys via WKD ...                                                                                   [ ok ]
 * Trusted signature found on top commit
=== Sync completed for gentoo

Action: sync for repo: gentoo, returned code = 0




which should not happen for ::gentoo IMO.
Comment 1 Mike Gilbert gentoo-dev 2023-05-18 21:20:17 UTC
Could you share your repos.conf settings for the gentoo repo? I would guess this is related to a shallow fetch depth.
Comment 2 Mike Gilbert gentoo-dev 2023-05-18 21:25:18 UTC
Oh, I see fetch depth is 1.

> /usr/bin/git fetch origin --depth 1
Comment 3 Toralf Förster gentoo-dev 2023-05-19 07:06:29 UTC
# cat /etc/portage/repos.conf/all.conf 
[DEFAULT]
main-repo = gentoo

[gentoo]
location = /var/db/repos/gentoo
auto-sync = yes
sync-type = git
sync-uri = https://github.com/gentoo-mirror/gentoo.git
sync-git-verify-commit-signature = true
priority = 10
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-12-14 08:47:24 UTC
flow, would you mind looking at this?
Comment 5 Florian Schmaus gentoo-dev 2023-12-14 13:01:25 UTC
I would expect that "git gc" should remove the unreachable loose objects. The man page of "git prune" even tells us "In most cases, users should run git gc, which calls git prune. See the section "NOTES", below."

So the unreachable loose objects should be gone after "git gc" and this repo configuration should lead to "git gc" being invoked.

However, we invoke "git gc" with --auto. Maybe this is an issue? Why are we adding --auto here?
Comment 6 Florian Schmaus gentoo-dev 2023-12-14 16:46:07 UTC
After looking at the git source code, it appears we have the following options: 
  1. Do nothing (because I am not yet positive that there is an actual issue, or it is at least an issue that will not eventually self heal)
  2. run "git gc" without --auto
  3. conditionally or unconditionally run "git prune" in addition to "git gc"

On a side note: I've grepped sync logs going back multiple months on two of my machines that use the "canonical" ::gentoo git setup (shallow clone with depth=1) and could not find any "too many unreachable loose object" messages.

@toralf: do you experience that affected repositories "heal" themselves?
Comment 7 Toralf Förster gentoo-dev 2023-12-14 16:55:07 UTC
(In reply to Florian Schmaus from comment #6)

> @toralf: do you experience that affected repositories "heal" themselves?

No, but it is now few months ago since I was faced with that.