There was a comment earlier about a PyQt4 <-> PyQt5 Error with slickpicker and mikidown on mikidown. I woke up thinking that it was due to them not updating a PKGBUILD, but...
https://aur.archlinux.org/packages/slickpicker/
https://aur.archlinux.org/packages/slickpicker-git/
I checked the AUR3 archive and the data up there only matches the initial import.
Even more disturbing is the fact that the comment I left about putting a proper pkgver() on slickpicker-git is missing. That was something I clearly remember doing this month.
Can someone check the activity log of the AUR servers? I'm pretty sure there had to be some unusual activity because I clearly remember updating those packages for their pyqt5 updates.
I'll be re-putting the updates on the AUR.
Hopefully they don't disappear this time. I'll have to make local clones of all my AUR packages so this doesn't happen again.
On 08/31/2016 01:36 PM, ShadowKyogre via aur-general wrote:
I'll be re-putting the updates on the AUR.
Hopefully they don't disappear this time. I'll have to make local clones of all my AUR packages so this doesn't happen again.
Why do you not already have local clones?
It seems a bit... inefficient... to re-clone a repository under someone else's control every time you want to update something.
So, why should AUR packages be different from any other form of source code?
...
If you want a good example of a way to manage multiple AUR packages, this is what I do (uses git subtrees): https://github.com/eli-schwartz/pkgbuilds/tree/base
It has the advantage of preventing common maintainer mistakes (forgetting to update .SRCINFO/updpkgsums, autofilling default commit messages, handling remotes on-the-fly for new packages, etc.)
Basically, additional reasons for being ordered about this sort of thing, in case you weren't convinced already. :)
It seems a bit... inefficient... to re-clone a repository under someone else's control every time you want to update something.
So, why should AUR packages be different from any other form of source code?
It shouldn't be. I just haven't gotten around to setting up a git repo somewhere else to mirror my AUR PKGBUILDs. That being said, at the time of writing the OP, I was scrambling for a local copy before panicking and running off to the mailing list.
Thankfully most of them are cloned now, so this shouldn't be much of a problem.
If you want a good example of a way to manage multiple AUR packages, this is what I do (uses git subtrees): https://github.com/eli-schwartz/pkgbuilds/tree/base
It has the advantage of preventing common maintainer mistakes
(forgetting to update .SRCINFO/updpkgsums, autofilling default commit messages, handling remotes on-the-fly for new packages, etc.)
Basically, additional reasons for being ordered about this sort of thing, in case you weren't convinced already. :)
Oh sweet! I currently just have a dedicated subfolder for my AUR PKGBUILDs, but none of the niceties that this provides. Thanks a bunch!
On 09/01/2016 01:04 PM, ShadowKyogre via aur-general wrote:
Oh sweet! I currently just have a dedicated subfolder for my AUR PKGBUILDs, but none of the niceties that this provides. Thanks a bunch!
Happy to help. :)
Notice, it even has a function to import pre-existing AUR packages, if you just started using my aurpublish manager or alternatively became (co-)maintainer of a previously-uploaded package.
I tried to include anything that I thought could be useful, and since I haven't touched the scripts/hooks in a while, I figure I have probably succeeded. :D
Feel free to mention anything you think could be done better, or would be nice to additionally do.
aur-general@lists.archlinux.org