Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.

FS#62870 - [makepkg] does not update tags in src/ folder checkout

Attached to Project: Pacman
Opened by Donald Webster (fryfrog) - Monday, 10 June 2019, 21:55 GMT
Last edited by Allan McRae (Allan) - Friday, 11 October 2019, 10:26 GMT
Task Type Bug Report
Category General
Status Assigned
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 5.1.3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No



Working with the `linux` package as acquired via `asp` in this example. The initial `makepkg` will checkout a bare git repo in the `./` of the package, then an actual git repo is created in `./src`. The build works. But when a newer kernel is released, the `makepkg` does *not* get new tags in the git repo in `./src`. In the example pastebin, you can see the bare repo is up to date and so `git fetch -v` reflects that. But in the checkout in `./src`, `git fetch -v` doesn't fetch tags, but `git fetch -v -t` does *and* gets the new tag.

Steps to reproduce:

Checkout `linux` package
Wait until a new kernel releases
Update it via `asp update`
Try to run `makepkg` for the new kernel
This task depends upon

Comment by Eli Schwartz (eschwartz) - Tuesday, 11 June 2019, 04:42 GMT
EDIT: nvm, misread paste.

Okay, so apparently the archlinux-linux repository has a detached tag, which, since it doesn't exist on any branch at all, will never be fetched (although it will be cloned). Honestly, this is entirely unexpected behavior and repositories that hide their hidden orphaned tags are going to be confusing more than just makepkg. :(
Comment by Donald Webster (fryfrog) - Tuesday, 11 June 2019, 04:48 GMT
This is my `config` from both of the checkouts it created. I'm not sure how I can reproduce it w/o waiting for a new tag to appear. How did you? Just happened to already have it, but not updated? But this happens on *both* of my Arch servers. I can blow everything away and re-start the whole thing from scratch w/ the initial checkout via `asp checkout linux`.

0 ✓ fryfrog@apollo ~/asp/linux/repos/core-x86_64/archlinux-linux $[master] cat config
repositoryformatversion = 0
filemode = true
bare = true
[remote "origin"]
url =
fetch = +refs/*:refs/*
mirror = true

0 ✓ fryfrog@apollo ~/asp/linux/repos/core-x86_64/src/archlinux-linux $[makepkg*] cat .git/config
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = /home/fryfrog/asp/linux/repos/core-x86_64/archlinux-linux
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Comment by Eli Schwartz (eschwartz) - Tuesday, 11 June 2019, 05:07 GMT
The problem is it is an orphaned tag, yeah. So it is an issue when cloning the repo, then expecting later fetches to be capable of functionally, well, fetching content. The repo is broken, the question is whether we should try to handle such cases?

This would also be an issue, for example, when using a commit sha1 if the branch it came from is deleted from the standard refs.

... I'm unaware of any package this issue has ever affected other than core/linux. But I could say the same about other makepkg issues too.
Comment by Donald Webster (fryfrog) - Tuesday, 11 June 2019, 05:12 GMT
There clearly aren't many people effected by this, but it was a little annoying to figure out. It's pretty easy to deal with and I'm sure I'll forget as soon as I stop needing to build the kernel. :)