- Aur-general - lists.archlinux.org

[aur-general] laptop broke, co-maintainers needed.
by zoorat 10 Jan '22

10 Jan '22

hey everyone, i was maintaining few packages for a while now... but my laptop fan broke and cant find the necessary part anywhere to fix this thing, and my family is not interested about letting me buy another one, at least not now, because i have a major exam ahead... it sucks. anyway, i want some co-maintainer who can keep those packages update to date for now, i will try to get back as soon as possible. if you want to co-maintain then please reply to this mail with your username, and i dont have any requirement but i hope your account it quite old... i will get back in few days and make you the co-maintainer, thanks a lot for helping me. btw, i dont know much about co-maintaining... tell me what i should do and shouldn't... yours, zoorat. p.s. im in rush, dont mind my bad english.

5 7

Re: [aur-general] laptop broke, co-maintainers needed.
by Amin Vakil 09 Jan '22

09 Jan '22

> if you want to co-maintain then please reply to this mail with your username, > and i dont have any requirement but i hope your account it quite old... > i will get back in few days and make you the co-maintainer, > thanks a lot for helping me. > I can help co-maintaining python-spotdl. My username is aminvakil. Best Regards, Amin Vakil

1 0

[aur-general] Request to add makedumpfile to community repo
by Guilherme G. Piccoli 07 Jan '22

07 Jan '22

Hi folks, first of all thanks for maintaining Arch Linux - it's a very great distro to use! So, I'm working in a potential kdump package for Arch - I've been working for some time in Ubuntu/Debian kdump and it was a surprise when I started to use Arch and noticed that we don't have a kdump package (or in case we have something, please let me know and apologies in advance). Anyway, kdump functionality requires some components, like kexec, makedumpfile (to collect compressed dumps - a must if you ask me) and the crash utility to analyze the core dumps (although there are more tools for that). Currently, both kexec and crash are present in the official repositories (extra and community, respectively). Makedumpfile is maintained in AUR - very well maintainer I should add, thanks to Maurizio. But I'd like to request, if possible, to bump makedumpfile to community repository - I think it makes sense to have this package in the repos along with crash and kexec, so a potential kdump package in AUR would depend only on pre-built official packages. I'd like to help making that happen - just let me know what I can do. By reading the documentation in the wikis, it seems it's a good idea to propose packages that: - have at least some votes -> makedumpfile is OK in this respect; - well-maintained in AUR -> ditto for makedumpfile; - are useful -> I consider makedumpfile very useful, I'd say essential for kdump; So, if any TU wants to adopt it, I'd be really happy and grateful. Thanks in advance, and please let me know your feedback on this request. Cheers, Guilherme

1 0

[aur-general] Stop deleting texlive-dummy and texlive-upstream
by slbtty 05 Jan '22

05 Jan '22

Hi, It is obviously the one who request and confirm the deletion of the texlive-dummy and texlive-upstream doesn't know why they are existed. The delection request this [1] : """ Dummy pkgbuild which wrongfully conflicts and replaces texlive system packages """ Exactly! We don't want to use the system texlive at all. We want the conflict and replace the system texlive. The texlive in official repo is out-dated and unable to pull other packages from CPAN. The system texlive and the dependencies on it is broken. The TeXlive installed by official installer (from texlive.org) is superior and much better for serious users, and we really don't need the system one. If you google "archlinux texlive dummy", you know what ? You can get a lot of pages about "texlive dummy package on AUR". However, the package is GONE. Stop breaking this existing, proven to work and perfect solution. Please stop deleting them! Please restore both texlive-dummy and texlive-upstream. Please check how many upvotes and popularity that those two packages got. [1] https://lists.archlinux.org/pipermail/aur-requests/2022-January/064689.html https://lists.archlinux.org/pipermail/aur-requests/2022-January/064789.html https://lists.archlinux.org/pipermail/aur-requests/2022-January/064691.html slbtty

2 1

[aur-general] Clarification for Deletion request #30701
by silentnoodle 03 Jan '22

03 Jan '22

hey all, Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied. So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… Cheers, Ben a.k.a silentnoodle

16 34

Re: [aur-general] Why were my 'makedeb-beta' and 'makedeb-alpha' packages deleted?
by George Rawlinson 20 Dec '21

20 Dec '21

> On 18/12/2021, at 20:46, Hunter Wittenborn <hunter(a)hunterwittenborn.com> wrote: > > Unless you want to discuss anything further, could I just get a final answer on if my packages can be put back on the AUR, and then we can just leave it there? I really don't want to argue a ton, but there's a fair bit of frustration involved when I have packages that I'd like to be used in production just being deleted without a chance for me to even intervene. Yep, go for it. I didn’t see the posts on aur-general, having only searched aur-requests for any replies. That’s on me, apologies for that.

1 0

[aur-general] Please disregard my deletion request for linux-slim
by kiasoc5＠tutanota.com 20 Dec '21

20 Dec '21

Please ignore my deletion request for linux-slim [1]. I thought the package would be too niche but there are some users of it per the package comments. Perhaps now is a good time to clarify what the wiki means by an "extremely specialized" package? [1] https://lists.archlinux.org/pipermail/aur-requests/2021-December/063787.html Thanks kiasoc5

2 1

[aur-general] Why were my 'makedeb-beta' and 'makedeb-alpha' packages deleted?
by Hunter Wittenborn 18 Dec '21

18 Dec '21

Forwarded from mailto:aur-general@lists.archlinux.org, as it doesn't appear to have sent there. ============ Forwarded message ============ From: Hunter Wittenborn <hunter(a)hunterwittenborn.com> To: "aur-requests"<aur-requests(a)lists.archlinux.org> Date: Wed, 15 Dec 2021 23:28:09 -0600 Subject: Why were my 'makedeb-beta' and 'makedeb-alpha' packages deleted? ============ Forwarded message ============ Hi, I just received some emails about an hour ago that my 'makedeb-beta' and 'makedeb-alpha' packages were deleted off of the AUR because they were duplicates of 'makedeb' [1] [2]. I'm a bit confused on how exactly they're "duplicates" of makedeb though, as they're literally the beta and alpha releases for makedeb, the lattermost being the stable release. The only other hypothesis I'd have is that the underlying program is the same, but these are all different releases, and they're all being published so users can use whichever channel they chose. My packages also aren't the only ones following a multi-channel packaging system on the AUR, so I'm not really sure why my packages got flagged like this in particular. Could I get an explanation for all of this? I'm quite confused on how I could have messed up - recloning the PKGBUILDs for 'makedeb-beta' and 'makedeb-alpha' on my local system is also still clearly showing the differences between the three packages. [1]: https://lists.archlinux.org/pipermail/aur-requests/2021-December/063223.html [2]: https://lists.archlinux.org/pipermail/aur-requests/2021-December/063222.html --- Hunter Wittenborn mailto:hunter@hunterwittenborn.com https://www.hunterwittenborn.com https://github.com/hwittenborn

4 7

[aur-general] Regarding deletion request #30697 (waybox)
by Lex Black 16 Dec '21

16 Dec '21

Good day list, I'm currently a little bit stumped about this particular request. I wouldn't have said anything if there were the right reason named for deletion. One reason would be, that due to upstream stagnation the waybox release could only be compiled with an older wlroots versions. Would have been a fair point and I was aware of that restriction. But what happened instead? I got a OOD Mail, 2 min later a deletion request[0] was issued. And eight minutes down the road this request got already accepted. Hella speedy process. If I recall the requests I made, there was time involved for checking if I made a reasonable request. But again: There were reasons why a request could have been valid. So let us take look: Regarding the OOD message: Quote: "This branch is 32 commits behind wizbright:master." Well, yes. But we are talking about a release from a tagged release. We aren't talking about waybox-git. And yes, it wasn't the main repo, but it was the personal repo from the last active developer. He did tag only in his repo as he wasn't the owner[1]. Regarding the request: Quote: "th1nhhdk [1] filed a deletion request for waybox [2]: -There's no "release", only the git version exists -Maintainer's custom repo is outdated -Maintainer don't want to maintain this package anymore" Okay, first point is debatable. But from my point of view were the tags from someone who actively contributed in the main repo and knew what he was doing. Second point is in my opinion not valid, as it build from a tag. But what maintainer are we talking about? The waybox maintainer or the PKGBUILD maintainer? If the latter. Well... I have nothing to do with this so called custom repo. And now the third point: Again. What maintainer? I got reprimanded in the past for requests that made it difficult when looked at a later point. And this was only a few hours ago. Although I must admit I cannot recall if I pinned a comment regarding the status with recent wlroots packages. But I'm fairly sure I didn't orphan the package (well, I got the OOD-message) and I didn't leave a comment like the previous maintainer of the PKGBUILD, who wrote an agiated message when he dropped it. So what do I want, after I writing this wall of text? In a tone which will likely come around as angry (kinda, but only at the situation and how it went and not the persons involved). Nothing in particular. I won't reinstate the package, as a deletion request with the right argument could have been deemed valid. My main gripes with this request in particular is the following point: * No time for me to react as the whole thing went down in 10 minutes And as far as I can tell, there was no attempt in making contact beforehand. I was even attempting to look at this again as someone informed me about a possible missing build dep. And was there even a check if the arguments were valid? In the past it took some time before requests were accepted. Orphaned, ood and truly dead sources were removed faster of course, but it could still be vetoed. But this one? One with a fairly active maintainer? Not so much. But whatever. It happened. Best regards ____________ [0] https://lists.archlinux.org/pipermail/aur-requests/2021-December/063697.html [1] https://github.com/wizbright/waybox/issues/25

2 1

[aur-general] Customize testing in PKGBUILD
by Jan Kohnert 14 Dec '21

14 Dec '21

Hi, I'm maintaining the eccodes aur package and would like to enable some extra tests in PKGBUILD. This can be done by downloading extra testdata and put that into the main build dir. As good as this may seem, it significantly blows up the build time of the package. So I thought about somehow let the user decide whether to run those expensive extra tests at build. Unfortunately I could not find a recommended way of doing so. Would it be an option to check an environment variable, call it ENABLE_EXTRA_TESTS or so, and run those stuff only if set? And otherwise just run the usual tests without the extra data? Any thoughts? Thanks! -- MfG Jan

5 5