- Aur-general - lists.archlinux.org

Re: got a laptop
by zoorat 13 Nov '23

13 Nov '23

sure, i will do that if it works already picked up some pkgs like that :) and what if its broken ?? On 11/13/23 10:32, aur(a)nullvoid.me wrote: > I feel most users just want it to work, instead of maintaining it properly. So if you see out of date packages over 2-3 year that still "work" why not try to adopt them, instead of deleting them. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

1 0

Re: got a laptop
by zoorat 13 Nov '23

13 Nov '23

hi, thanks for the answer. but i think i asked the question in the wrong way. when i was testing out-of-date packages there were some with out-of-date flag before 2020 but those works i was meaning to ask, **how long does the package have to be out of sync with the main source ??** also i found some pkgs with depreciated `git://` but those works after modding it with `git+https://`. i generally report them if and only if they are orphans. On 11/13/23 04:51, aur-general-request(a)lists.archlinux.org wrote: > "David C. Rankin" <drankinatty(a)gmail.com> writes: > >>> 2. should AUR host out-of-date but working packages ?? >>> >> >> There is always a sliding-scale of "How out-of-date?". Is some user of >> the package just flagging it 10 minutes after the latest upstream >> change? >> >> Is a dependency no longer supported by Arch (that's what AUR is >> for...)? >> >> Some packages may not have been updated in quite a while, but may be >> 100% valid and still good. >> >> This is hard to give advise on without knowing more about what you are >> considering "out-of-date"? > > I want to add that sometimes the maintainer might be already > working on an update but didn't release it. > It's easier to branch of a package and test it until merging it to the > AUR sometimes. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

2 1

got a laptop :)
by zoorat 12 Nov '23

12 Nov '23

hi, i am the same guy from https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org… got a system with archlinux after a long time. it took way too long because my exam just got delayed and delayed then on top of that, some other stuff stupid happened... currently got into a university and studying CSE. during this time, i used an archlinux container from an old mac to keep my cli packages up to date. still using that mac but flashed it with linux. i wanna thank all those people who tried to help me fix my laptop and set up a server to keep maintaining my packages, i can't explain how happy those emails made me. and also thanks to all who co-maintained my packages. thanks a lot mate. i'm back reporting broken packages in AUR. already 52 pending :) love this new /requests page, wish it had some personal stats. but as i wasn't very active on the mailing list, i don't really know much about new or changed rules. please tell me what changed and what i should not do. some questions: 1. is it ok to file deletion req for not orphan also not out of date package ?? should i first try to contact the maintainer and if he does not update, should i file req then ?? what if there is no way to contact him ?? 2. should AUR host out-of-date but working packages ?? 3. is it ok to ask people to be co-maintainer for their pkgs ?? 4. review my PKGBUILDs, please list: https://aur.archlinux.org/packages?K=zoorat&SeB=m 5. about TU ?? my 1224 deletion req was accepted, and 6 deletion req was rejected, 52 req is pending for now. (got this number by filtering by `notify(a)aur.archlinux.org` and searching for "has been rejected by" / "has been accepted by". don't know if it's right info tho) and i'm also maintaining some pkgs. is this enough ?? when i asked last time, @ainola told me my account was young. do i meet the requirements for being a TU ?? 6. shouldn't i remove inactive co-maintainers ?? thanks in advance. p.s. sorry about my English. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

4 3

Removal of Jonas Witschel (diabonas) as Package Maintainer
by Levente Polyak 09 Nov '23

09 Nov '23

Hi all, I'd like to start a "Special Removal of an Inactive Package Maintainer" [0] for Jonas Witschel (diabonas) based on prolonged inactivity. Jonas has not executed any packaging or AUR maintenance duties since a very long time. Due to this I tried to reach Jonas since quite a while over various channels. Finally I was able to get a response via Signal mid of January 2023. He promised to try to catch up with things that neglected, which unfortunately still didn't happen for his Arch responsibilities. Afterwards I've also tried to get a response in March, May, June and August, without success. Furthermore, gromit has also reached out independently while trying to reach all package maintainers that missed multiple votes, also without success. Hence we also started replacing Jonas as main key holder and I hereby start the Package Maintainer removal with this thread. The discussion period will last for three days, after which there will be a voting period of five days. Cheers, Levente [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an…

3 6

'gnome-passwordsafe' rename to 'secrets'
by Fabian Bornschein 09 Nov '23

09 Nov '23

Hi! :) gnome-passwordsafe was renamed to "secrets" 2 years ago[0]. As per FS#80135[1] there is a open bug report. The secrets package is available in extra-testing[2] for a week, tested (install, upgrade from gnome-passwordsafe, uninstall + reinstall) and seems looks good to me to move. Since this is a new package the rules[3] require to post this on the mailing list and find 3 other maintainers that agree on it to move to extra (and of course to remove gnome-passwordsafe[4] and the AUR PKGBUILD[5] in the process). [0] https://gitlab.gnome.org/World/secrets/-/commit/65720af5023cc5a08e31076cfe0… [1] https://bugs.archlinux.org/task/80135?project=1&string=secrets [2] https://archlinux.org/packages/extra-testing/any/secrets/ [3] https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_pa… [4] https://archlinux.org/packages/extra/any/gnome-passwordsafe/ [5] https://aur.archlinux.org/packages/secrets -- Fabian Bornschein <fabiscafe(a)archlinux.org>

2 1

Disowning my mingw packages
by Ivan Puntiy 06 Nov '23

06 Nov '23

1. For a few years now I no longer work with C++ as my primary language. 2. Due to a war in my region I no longer have access to my home computer with Arch installation. 3. There keeps coming action requests on them, that I can't currently act upon. Therefore I'm disowning my following AUR packages, and they are free for adoption by a willing individuals: * mingw-w64-wxmsw * mingw-w64-wxmsw3.1 * mingw-w64-libdxfrw Ivan.

1 0

[aur-general] TU rename Bylaws amendment vote
by Konstantin Gizdov 25 Oct '23

25 Oct '23

Hi, As per the TU Bylaws following the discussion to rename the Truster Users [1], the Trusted Users themselves must vote to approve the renaming. Hence, please, cast your vote on whether you agree the Bylaws be amended and the "Trusted User" role is renamed into "Package Maintainer". Vote is located at - https://aur.archlinux.org/tu/140 -- Regards, Konstantin [1] - https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7

2 6

PKGBUILD review request for displaylink-runit
by Eric 21 Oct '23

21 Oct '23

Hi all, I'm working on this PKGBUILD to provide a displaylink-runit service. I use an Artix based distro using runit instead of systemD as the init system. Before I publish this, please review this. I have posted the link to my PR to a few Linux communities and I have addressed their comments, so hopefully that takes care of my small mistakes haha. If you have the hardware to test, that would be great! https://github.com/e-dong/aur-displaylink-runit/pull/1 References: https://aur.archlinux.org/packages/displaylink https://wiki.archlinux.org/title/DisplayLink Best, Eric

3 3

Dealing with unclear upstream licensing and legality
by netsysfire＠das-labor.org 27 Sep '23

27 Sep '23

abgx360 has been deleted recently (see https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/…) I noticed it because https://wiki.archlinux.org/title/Burning_Xbox_360_games has a broken link. There are two reasons for the deletion: 1. Legality of home backups. Though we have stuff like popcorntime in the AUR or even whipper in extra, so it should not matter. 2. Bad licensing. There is no upstream license set, thus applying the default copyright rules: > You're under no obligation to choose a license. However, without a > license, the default copyright laws apply, meaning that you retain all > rights to your source code and no one may reproduce, distribute, or > create derivative works from your work. However, as the AUR only ships PKGBUILDs we are neither reproducing or distributing it and it does also not seem like a derivative work. Alad already poked upstream about this. https://github.com/BakasuraRCE/abgx360/issues/7 This was also painstakingly discussed on IRC in both -aur and -wiki, leading to walls of text. Antiz made the decision to delete in good faith and there was apparently also an internal discussion in the staff channel, which we agreed on should have been public. My opinion is that the package should be restored. I do not even use it and only noticed because of said dead link, yet the decision feels off. Antiz said that they are rethinking it, too.

7 12

Possible duplicate or bad naming (greenclip and rofi-greenclip)
by Polarian 26 Sep '23

26 Sep '23

Hello, I have found the following two packages: https://aur.archlinux.org/packages/greenclip https://aur.archlinux.org/packages/rofi-greenclip At first by name they seem like duplicates, but it seems greenclip is a source package and rofi-greenclip is a binary package but has not added the -bin suffix which has caused duplication. I can't really "flag for bad naming" so I decided to post it here to bring attention to it so it can be fixed. As greenclip is an open source project a binary package should be suffixed with -bin as per the packaging guidelines, so although greenclip is a duplicate it is actually correctly named unlike the latter. As it seems to be a rofi integration the name "rofi-greenclip" does seem like a much better name, so I would suggest the following: - rofi-greenclip is renamed to rofi-greenclip-bin as it is a binary package. - greenclip being a source package is named correctly, however as it is a rofi addition it might be better to rename it to rofi-greenclip, but there is no conventions to the best of my knowledge which "force" this rename, just a possible improvement. Let me know if I have misunderstood or made any mistakes, or if you disagree with my suggestion :) Also I hate to point this out, but the reason I found this was editing the ArchWiki, I am not playing moderator, an wiki page can not provide the right package name if there is two packages which are conflicting one another. I had to point this out to prevent bad faith so I apologise for being defensive. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)icebound.dev

2 4