[aur-general] Fwd: [REPORT] Banned for reporting Out of Date CVS packages by Alucryd
---------- Forwarded message ----------
From: Ake Doragon no Namida
Hi, can you look at your packages? For example this package is out of date for more than 6 months.
You have a lot of packages and a lot is up to date, so it is just a little request.
If you can, please update "not popular" sometimes, when you have free time or you can do it
https://aur.archlinux.org/packages/pantheon-files-plugin-dropbox-bzr/
// updated after mail https://code.launchpad.net/~elementary- … in-dropbox https://code.launchpad.net/%7Eelementary-apps/pantheon-files/pantheon-files-... , ok, without any answer on mail. (nothing wrong anyway)
Hi,
Will you please stop flagging CVS packages that need absolutely no updating ? More than half of what you flagged builds perfectly fine and is not out of date. While the others do need some changes (which I already did or will this week) you will find that I have close to no patience and might get temporarily banned really soon if you keep trying it.
Cheers, -- Maxime
// Ok, so this guys mean: if i have installed new version (for example 10) a year ago, and i want update my package to new version (f.e.55) i must remember this package name and reinstall it manually, cos *pacman -Syu* or *yaourt -Syyu* will not work. And what when i will have 200 packages on my PC with this like "out of date" version in aur? Maybe pkgbuild is always UP to date, but version what is in AUR *IS NOT*
*BANNED? For what?* https://www.archlinux.org/packages/flaghelp/ -- nothing about CVS packages https://wiki.archlinux.org/index.php/Ta … a_CVS_repo https://wiki.archlinux.org/index.php/Talk:VCS_package_guidelines#Updating_a_... -- first line what is written
CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added.
i don't know what is going on, and why some of Thrusted Users are a little
d*cky (maybe just this guy), but that's not a nice look for *Arch Linux Distribution*. Even for Thrusted Users Arch is rolling distribution what does mean, always up to date. So to keep that initiative i am looking for Out Of Date packages and flagging them with link to last update or last version. Sometimes packages are running from git to sourceforge of from git repo to other git repo (i found 1 package with this mind*uck, official move wat was written on official website of package). But anyway it is not thing for wich i should be banned. **uck* or *d*ck* mean *duck* Looking for unban, justice and TU should respect the laws
On 11/04/2016 02:13 PM, Ake Doragon no Namida via aur-general wrote:
Arch is rolling distribution what does mean, always up to date. So to keep that initiative i am looking for Out Of Date packages and flagging them with link to last update or last version.
arbitrarily "bumping" VCS packages doesn't gain anything other then creating fuzz and satisfy shitty AUR wrappers -- it should be avoided at all means. With VCS packages there is noting like "out of date" in the classical term and such PKGBUILD should only be altered when there is actual change (f.e. in the dependencies or the build process). You either need to remember, or look for something like a --devel switch in your AUR wrapper. cheers, Levente
On 11/04/2016 09:35 AM, Levente Polyak wrote:
arbitrarily "bumping" VCS packages doesn't gain anything other then creating fuzz and satisfy shitty AUR wrappers -- it should be avoided at all means. With VCS packages there is noting like "out of date" in the classical term and such PKGBUILD should only be altered when there is actual change (f.e. in the dependencies or the build process).
On the contrary, it satisfies all AUR wrappers, whether they have a --devel flag or not. I don't always want to try rebuilding all devel packages to check for updates, so getting a notification that there is a newly-published release is not actually offensive to me. I don't expect AUR maintainers to automatically do that for me... but *I don't get pissed off when they do* and I don't understand why you seemingly do. Are you suggesting that I am actually a horrible AUR maintainer because I sometimes bump VCS packages for new versions? (I don't bump calibre-git because it is released on a regular schedule. Other things that are infrequently released I often will. And I maintain several packages as both release and *-git packages, so it is easy to bump them both at the same time...) Show me the rule that says it is actually forbidden for me to do so, or show me what "fuzz" it creates that actually causes people non-imaginary grief, and I will stop. But I think you are overreacting. -- Eli Schwartz
On 11/04/2016 02:55 PM, Eli Schwartz via aur-general wrote:
Show me the rule that says it is actually forbidden for me to do so, or show me what "fuzz" it creates that actually causes people non-imaginary grief, and I will stop.
But I think you are overreacting.
There are no stone plates, its just useless Sisyphos work without any real value. A VCS package should be considered to possibly always have a new version, no need for a ranger to periodically bump those just to possibly satisfy shitty AUR wrappers that maybe don't have something like a --devel option. I don't think its worth trying to comfort all AUR wrappers in the way a PKGBUILD is handled. I have seen too often including horrible hacks here and there because one wrapper does or doesn't do X or Y and fails.Its not as harmful because at the end its just a different pkgver but the conclusion is the same: No gain other then to satisfy AUR wrappers. Therefor my personal opinion is to avoid that all together no matter if you think that it is overreacting or not.
On 11/04/2016 10:20 AM, Levente Polyak wrote:
I don't think its worth trying to comfort all AUR wrappers in the way a PKGBUILD is handled. I have seen too often including horrible hacks here and there because one wrapper does or doesn't do X or Y and fails.Its not as harmful because at the end its just a different pkgver but the conclusion is the same: No gain other then to satisfy AUR wrappers. Therefor my personal opinion is to avoid that all together no matter if you think that it is overreacting or not.
That wasn't initially clear from what you said. :) I will stick with making sure the PKGBUILD is well-written then, and if I feel in the mood, commit the changes makepkg itself makes to the PKGBUILD. ;) (No real gain != loss) And I don't really see it as a "workaround for AUR wrappers". I see it as getting more useful information into the AUR rpc interface. It's similar to why I make sure to bump the pkgrel to trigger a rebuild for soname bumps -- and there are people who insist that AUR users should be required to check for that by hand. -- Eli Schwartz
On 11/04/2016 06:17 PM, Eli Schwartz via aur-general wrote:
(No real gain != loss)
Looks like our conclusion about this distinguishes as for me doing something without gain is a loss. nvm. I don't like it much, but if we are talking half-way about AUR wrappers anyway then don't forget that the loss is that you force it to be part of "regular" updates of those wrappers. As Philipp pointed out you have a gain when taking them separately into account as you want to be more careful because of possible wonky states.
And I don't really see it as a "workaround for AUR wrappers". I see it as getting more useful information into the AUR rpc interface.
Why not setup a systemd timer then and sync the version once per minute so it has even more up-to-date useful information?
First of all, the formatting of your email is completely shit. On 04/11, Ake Doragon no Namida via aur-general wrote:
// Ok, so this guys mean: if i have installed new version (for example 10) a year ago, and i want update my package to new version (f.e.55) i must remember this package name and reinstall it manually, cos *pacman -Syu* or *yaourt -Syyu* will not work.
Yes, that is how VCS packages work. Either suck it up, or stop using them.
And what when i will have 200 packages on my PC with this like "out of date" version in aur? Maybe pkgbuild is always UP to date, but version what is in AUR *IS NOT*
The pkgver field in VCS PKGBUILDs in the AUR mean nothing.
https://www.archlinux.org/packages/flaghelp/ -- nothing about CVS packages
https://wiki.archlinux.org/index.php/Talk:VCS_package_guidelines#Updating_a_... -- first line what is written
CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added.
None of these packages seem to be CVS packages, so I don't see how this is relevant. Either way, the quoted line would probably still be irrelevant if there were.
i don't know what is going on, and why some of Thrusted Users are a little d*cky (maybe just this guy), but that's not a nice look for *Arch Linux Distribution*. Even for Thrusted Users
Arch is rolling distribution what does mean, always up to date. So to keep that initiative i am looking for Out Of Date packages and flagging them with link to last update or last version.
AUR VCS PKGBUILDs can by definition not be out of date, unless they're out of date in the sense that the build process has changed.
Sometimes packages are running from git to sourceforge of from git repo to other git repo (i found 1 package with this mind*uck, official move wat was written on official website of package).
I have no idea what you're trying to say here.
But anyway it is not thing for wich i should be banned.
Looking for unban, justice and TU should respect the laws
1) I might unsuspend you, but I'm feeling doubtful that you're going to change, so probably not. 2) Justice is what has been served. 3) Which exact "laws" are we not following? Anyway, I also sent you an email 2 days ago after suspending you for flagging jasonwryan's VCS packages out of date over and over, which you haven't replied to. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
Looking for unban, justice and TU should respect the laws
1) I might unsuspend you, but I'm feeling doubtful that you're going to change, so probably not.
This guy has some annoying communications habits that hit me as well a week ago. Not only does he barely comply to any social rule of communication, he also seems not to read or understand replies and thus inaccessable to any constructive form of correspondence. I'd rather like to not seeing him unbanned, although this might not stop him for long this does send a signal. I'm not going into detail, as this is not closely related. Details provided when necessary. Best regards georg
On 11/04/2016 09:13 AM, Ake Doragon no Namida via aur-general wrote:
Hi, i have a problem with Alucryd from AUR. Just read and give me your opinion.
My opinion is that you are a troublemaker.
Will you please stop flagging CVS packages that need absolutely no updating ? More than half of what you flagged builds perfectly fine and is not out of date. While the others do need some changes (which I already did or will this week) you will find that I have close to no patience and might get temporarily banned really soon if you keep trying it.
Cheers, -- Maxime
// Ok, so this guys mean: if i have installed new version (for example 10) a year ago, and i want update my package to new version (f.e.55) i must remember this package name and reinstall it manually, cos *pacman -Syu* or *yaourt -Syyu* will not work. And what when i will have 200 packages on my PC with this like "out of date" version in aur? Maybe pkgbuild is always UP to date, but version what is in AUR *IS NOT*
So use the --devel flag for yaourt, which clones and checks all *-git/*-hg/*-svn/*-bzr packages to see if there is a new version. AUR helpers in general come with options to do this, that is why they are "helpers" -- because they help you.
*BANNED? For what?*
https://www.archlinux.org/packages/flaghelp/ -- nothing about CVS packages
https://wiki.archlinux.org/index.php/Ta … a_CVS_repo https://wiki.archlinux.org/index.php/Talk:VCS_package_guidelines#Updating_a_... -- first line what is written
CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added.
i don't know what is going on, and why some of Thrusted Users are a little
d*cky (maybe just this guy), but that's not a nice look for *Arch Linux Distribution*. Even for Thrusted Users
That would be "VCS" packages, as in version control, as in development versions that have one PKGBUILD which builds from the latest source whereby the PKGBUILD intelligently updates its own pkgver. According to the conversation you quoted, you weren't even banned for flagging them out of date, you were banned for continuing to do so after you were warned that that is not what you are supposed to do.
Arch is rolling distribution what does mean, always up to date. So to keep that initiative i am looking for Out Of Date packages and flagging them with link to last update or last version. Sometimes packages are running from git to sourceforge of from git repo to other git repo (i found 1 package with this mind*uck, official move wat was written on official website of package). But anyway it is not thing for wich i should be banned.
Updating the pkgver in a devel PKGBUILD does absolutely nothing other than allow automated tools to compare the latest development pkgver in the AUR to the one in your pacman database. It does not cause you to get more up-to-date packages, just rebuilding the same PKGBUILD gets you that (it is the fundamental definition of a devel PKGBUILD). Therefore quoting Arch Linux catchphrases gets you nowhere. And once again, as I read it you were banned for repetitively flagging packages out of date *after* you were informed that they were not, in fact, out of date, and shouldn't be flagged as such. ... Note: Personally, I often do update the *-git PKGBUILDs I maintain with the new versions... as a convenience for users, to notify them that a new release might have interesting features worth rebuilding for NOW. But that is a personal kindness on my behalf, done since I have the time and patience for it, and it is not okay to *demand* it of an AUR maintainer. It is also a low priority for me. If someone was being a nudnik to me about it, I would absolutely appeal to a TU to shut that person up.
Looking for unban, justice and TU should respect the laws
You have no sympathy from me. Not that I have the power to do anything about it, but even if I could, I wouldn't. Perhaps, instead of ranting in a disagreeable manner, you could try demonstrating that you realize the mistake you made, are sorry for the trouble it caused, and will endeavor to keep to the community standards in the future. Then maybe you will *deserve* to get unbanned. -- Eli Schwartz
2016-11-04 14:13 GMT+01:00 Ake Doragon no Namida via aur-general < aur-general@archlinux.org>: > > // Ok, so this guys mean: if i have installed new version (for example > 10) > a year ago, and i want update my package to new version (f.e.55) i must > remember this package name and reinstall it manually, cos *pacman > -Syu* or *yaourt > -Syyu* will not work. And what when i will have 200 packages on my PC with > this like "out of date" version in aur? Maybe pkgbuild is always UP to > date, but version what is in AUR *IS NOT* > > Yes, absolutely. You have to check those VCS packages yourself from time to time. By definition the VCS packages pull the latest development version from the VCS, it would be really pointless to update the package with each upstream commit. The packages are usually easy to identify, as their name should end with -git, -svn, -bzr etc. yaourt offers the --devel option, which will trigger an update of all VCS packages. If you don't want that maybe switch to release versions. Often there is both a release and VCS version for a specific software in the AUR. I really wonder why you need the latest development snapshots for 200+ packages :) Cheers, Phil -- Philipp Wolfer parolu – work together smoothly http://parolu.de
On Fri, 4 Nov 2016 15:14:16 +0100, Philipp Wolfer via aur-general wrote:
Yes, absolutely. You have to check those VCS packages yourself from time to time.
Not only in regards to new commits, but also in regards to soname issues. If somebody just wants to get a commit that fixes an issue, but later continue to use official releases, then it makes sense to edit a PKGBUILD and to drop the extension -git, -svn, -bzr etc., e.g. as I did for jack. root@ubuntu-mate:~# systemd-nspawn -qD /media/ubuntu-mate/archlinux pacman -Si jack2 | grep Ver Version : 1.9.10-4 root@ubuntu-mate:~# systemd-nspawn -qD /media/ubuntu-mate/archlinux pacman -Q jack2 jack2 1.9.10.r177.g7bdad49-1 However, if we want to build from git etc. in general, then we don't want to rebuild each package by each update, since hundreds of packages could be affected by unimportant commits or commits that break the software. Builds from git etc. should be handled wisely and not automagically. Regards, Ralf
participants (7)
-
Ake Doragon no Namida
-
Eli Schwartz
-
georg
-
Johannes Löthberg
-
Levente Polyak
-
Philipp Wolfer
-
Ralf Mardorf