Won’t build on Arch AUR

[MyopicPaideia]

Trying to install - getting this error in the PKGBUILD

==> Starting prepare()...
fatal: remote yshui already exists.
==> ERROR: A failure occurred in prepare().
Aborting...

Command 'makepkg --force' failed to execute.

Is it meant to refer back to the yshui repo??

[tryone144]

@frebib is the maintainer of the PKGBUILD in the AUR.

Looks, like a problem with the automatic rebase onto the yshui/next branch.
Possible brute-force workaround would be to run a clean-build with makepkg -C until the PKGBUILD is fixed.

[MyopicPaideia]

Thanks for the quick look - I will post this on the AUR site as well

[frebib]

The AUR package isn't exactly stable- I wasn't expecting it to be so popular!
Considering it rebases in upstream changes on every build, it's not surprising that it breaks so often. I have noticed the same issue with git remotes myself actually- it would be a lot easier if git had a stateless mode.

I think something like this should fix it, although it's still not perfect

diff --git a/PKGBUILD b/PKGBUILD
index 1e8e057..dd6e4d0 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -39,9 +39,8 @@ prepare() {
   export GIT_CONFIG_NOSYSTEM=1
   git config --local user.name makepkg
   git config --local user.email picom@makepkg.aur
-  git remote add yshui https://github.com/yshui/picom.git
-  git fetch yshui
-  git rebase yshui/next
+  git fetch https://github.com/yshui/picom.git next
+  git rebase FETCH_HEAD
 }

 build() {

I'd push the change, but it's currently failing to rebase again due to this change yshui/picom@9332cba

That raises the question: @tryone144 what is the reason you haven't upstreamed this yet? Is it incomplete? Unstable? I've been using it exclusively for a while now and it seems to be fine (most of the crashes are upstream bugs, not due to this feature)
I'll need a merge/rebase to be able to update the AUR package- this is clearly not sustainable in the long run. Perhaps I should maintain my own fork and resolve the conflicts myself?

[tryone144]

rebased and resolved the conflicts.

The AUR package isn't exactly stable- I wasn't expecting it to be so popular!

This is a similar problem I faced with the original implementation as well. 😄

That raises the question: @tryone144 what is the reason you haven't upstreamed this yet? Is it incomplete? Unstable? I've been using it exclusively for a while now and it seems to be fine (most of the crashes are upstream bugs, not due to this feature)

I haven't upstreamed this yet as I hadn't that much time to test my changes extensively. But given the popularity of the AUR package, it seems to run rather smooth except for the "experimental" backends part. I'll open a pull-request upstream to further discuss possibly needed changes in my codebase.

[frebib]

I've pushed a change @MyopicPaideia, can you try building the package now?

[MyopicPaideia]

@frebib Yes, just successfully built. Thanks so much for doing a great job maintaining this package. It is much appreciated!

[gardotd426]

Failing to build again.

==> Starting prepare()...
remote: Enumerating objects: 117, done.
remote: Counting objects: 100% (117/117), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 147 (delta 103), reused 115 (delta 102), pack-reused 30
Receiving objects: 100% (147/147), 25.67 KiB | 25.67 MiB/s, done.
Resolving deltas: 100% (106/106), completed with 19 local objects.
From https://github.com/yshui/picom
 * branch            next       -> FETCH_HEAD
Auto-merging CONTRIBUTORS
CONFLICT (content): Merge conflict in CONTRIBUTORS
error: could not apply 735efd6... Update CONTRIBUTORS
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 735efd6... Update CONTRIBUTORS
==> ERROR: A failure occurred in prepare().
    Aborting...
Error making: picom-tryone-git

[frebib]

>.< I don't know what to do about this. I'm starting to think that I should cut the rebase out of the pkgbuild, and have a separate package that does the rebase. It's unreasonable to expect this feature branch to be rebased every time yshui makes a change that causes a conflict.
Current conflict is with the contributors file, as you are now one :D
yshui/picom@7e29bb8
@tryone144 please close this issue, it's not a problem with your tree, but a problem with the package

[frebib]

I have fixed the conflict with some rebase magic (hackery)

[gardotd426]

Yep, it's currently working. Terribly, but that's another issue, the PKGBUILD is currently working though.

…

On Sat, Apr 11, 2020 at 4:21 PM Joe Groocock ***@***.***> wrote: I have fixed the conflict with some rebase magic (hackery) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM5Y33YS5DHQT4LCXXDEZ6DRMDGNNANCNFSM4LWTU6KA> .

[frebib]

Terribly

Yes, I agree. I can't have it both ways: keep it working (and have users happy) and not introduce hacks.
What do you think I should do?

[gardotd426]

I filed an issue on what I'm having trouble with

…

On Sun, Apr 12, 2020 at 5:03 AM Joe Groocock ***@***.***> wrote: Terribly Yes, I agree. I can't have it both ways: keep it working (and have users happy) and not introduce hacks. What do you think I should do? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM5Y3374DEA7QKCCZPDQCELRMF7VNANCNFSM4LWTU6KA> .

[tryone144]

Yes, I agree. I can't have it both ways: keep it working (and have users happy) and not introduce hacks.

That's the tradeoff between automatic rebase to keep it as current as possible and the added complexity of doing it manually in a separate branch.

What do you think I should do?

If stability is your main concern, doing the rebase manually in your own branch might be the best approach.