Search results for "moved to [extra]" - Aur-requests

Re: [aur-requests] [PRQ#15875] Deletion Request for python-semantic_version

by Eli Schwartz

On 9/1/19 10:58 AM, brent s. wrote: > On 9/1/19 10:29 AM, notify(a)aur.archlinux.org wrote: >> sl1pkn07 [1] filed a deletion request for python-semantic_version [2]: >> >> in [community] >> >> [1] https://aur.archlinux.org/account/sl1pkn07/ >> [2] https://aur.archlinux.org/pkgbase/python-semantic_version/ >> > > AUR maintainer for python-semantic_version here - wow, something got > goofed here! I think it was adopted into [community] without it being > removed from AUR. > > My last update[0] was 2017-11-24. The package was added to [community] > on 2017-12-06[1] but I never made a new commit to "re-create" the AUR > pkg or anything (as git history shows)... The [community] package is python-semantic-version. It was moved from the AUR, and the AUR version was deleted at the time: https://aur.archlinux.org/cgit/aur.git/log/PKGBUILD?h=python-semantic-versi… This package was first uploaded half a year after the package with a "-" instead of a "_" was first uploaded, however, the original version (not yours) was simply migrated from AUR 3 to AUR 4 ("Initial import" four days after the great migration began) so I'm not sure how long it existed before that. So your package was just a duplicate since its inception. Sorry. :( > Is that AUR removal process automatic or manual? If it's automatic, does > it warrant an auditing of other possible packages that were missed in > this fashion? It is manual, but you can see the list of duplicates using something like this: $ declare -f aurdupes aurdupes () { comm -12 <(pacman -Sql core extra community multilib| sort) <(curl -s https://aur.archlinux.org/packages.gz | gzip -d | sed 1d | sort ) } Since the package names are different, they don't even register as duplicates and you should be able to push to it just fine (which you *cannot* do for a package in community, as it would be added to the "this is in community" blacklist) -- Eli Schwartz Bug Wrangler and Trusted User

6 years, 1 month

Re: AUR Package deleted: xlibre-xserver

by Muflone

Hi > > 1. My primary reason for not providing Xorg was the extra > configuration required, especially with Nvidia cards. Usually, I would > expect Arch packages that claim `provides` to be a full drop-in > replacement. That is, when I `pacman -U` the new packages to replace > the old ones, everything should work out of the box (perhaps not > optimally without proper configuration, but at least without crashes). > Otherwise, this breaks non-interactive installations (goodbye, > pipelines and builds in a clean chroot) and causes many bug reports > from users who would not read the post-installation instructions > (although I agree they absolutely should). > > 2. Mixing XLibre and Xf86 packages is not possible, as there are > virtual `provides`/`conflicts` that prevent it. For example, > `xf86-video-*` conflicts with `X-ABI-VIDEODRV_VERSION<25.0` and > `X-ABI-VIDEODRV_VERSION>=26`, while `xorg-server` provides > `X-ABI-VIDEODRV_VERSION=25.2`. On the other hand, `xlibre-video-*` > conflicts with `X-ABI-VIDEODRV_VERSION<28.0` and > `X-ABI-VIDEODRV_VERSION>=29`, while `xlibre-server` provides > `X-ABI-VIDEODRV_VERSION=28.0`. These reported issues are software related, not packaging related. artist himself confirmed XLibre and xf86-* package cannot be mixed and it's the main incompatibility reason > if `xlibre-server-common` does not provide `xorg-server-common`, some > packages will fail to satisfy dependencies, most notably > `xorg-xwayland`. This is expected, as XLibre has dropped XWayland > entirely. Still, for many users, myself included, this creates an > issue since some DEs like Plasma 6 depend on `xorg-xwayland`. Also this one is a software related matter, coming from the option to use XLibre over Xorg, it's not a packaging thing and as packager there's nothing much you can do to fix, until you join the XLibre development team and discuss with them how to keep wayland working. > 4. I don’t see the logic behind the naming suggested by XLibre > maintainers. The Xorg package on Arch was named `xorg-server`, but the > new package should be `xlibre-xserver`? Where did the additional `x` > come from? The extra 'x' comes from the author fantasy, it's not different than call the server with a different name like XLibre-pingpong Regardless the author's decisions how to name their software, the downstream package should try hard to follow the author names, including changing the name if the author changes to something entirely different. > users if there is no clear advantage apart from matching the upstream > name. Distro packages, especially in the AUR, don’t have to follow > upstream naming, and, as expected, other distros running XLibre do not > agree on a single name either. We would be better off following the > Arch naming convention on Arch. AUR packages should match the upstream name, by following also the Arch Packaging standards too. Apart that, why shouldn't you follow their name? Only to keep the newer xlibre name as closing as possible the older xorg name? That's not a valid argument to me. > 5. Once I see a clear solution to the `provides` issue, I will update > the packages ASAP and will add `@xlibre` as a co-maintainer. The rest > of the duplicate packages (`xlibre-xf86-*` and `xlibre-x*-bin`) > should, of course, be deleted. Thank you for understanding the situation and trying to improve the collaboration between authors and maintainers. > P.S. I’m sorry for all the time and effort this has taken. I’m sure > things would move faster and more smoothly if the PKGBUILD author at > XLibre contacted me directly, since the only people I’ve heard from > were not related to packaging and simply repeated the same arguments > while unhelpfully calling me names. From my side, I apologize for not > adding the `provides` sooner. Please understand that I only wanted to > avoid breaking users’ X sessions, unlike some of the other reasons > people have assumed. > I've read a bit of extra discussions on different platforms and I'm not happy at all how the things were managed and how they tried to hijack the packages on AUR. For these reasons some xlibre packages were already deleted on AUR and xlibre-server is still still living in AUR, with the hope to find an agreement between the maintainer (vitaliikuzhdin) and the XLibre author (let's assume jcrowell is one of them). Please, regardless how the things were managed in the past, let's avoid to drag the discussion on different arguments as they won't even help to find a resolution. Thanks for you cooperation. -- Muflone

1 month, 2 weeks

Re: [PRQ#59191] Deletion Request for widevine Rejected

by Bart De Vries

Hi Fabio, >> To be honest, my preference would still be to merge both packages >> under the "widevine" name. I'm willing to maintain such a merged >> package. > > It won't happen as chromium-widevine is way more more popular, still > maintained, has a huge number of votes and comments, while widevine is a > mere duplicated package with a very strict use case, mainly to support > different architectures not supported by Arch Linux with only 1 vote and > only 6 months old. Well, maybe that's because there were previous packages with the same functionality that have been deleted from AUR before this one, which had more votes. (Those were ARM-centered, so I'm not going to argue about that here.) However, when those got deleted I asked the AUR trusted user what I would need to do to comply with the guidelines. I got the feedback that as long as the package would work for x86_64 and is well-maintained, it should be fine. So I spent the effort to make a universal package, only for it to get deleted again. This is so incredibly frustrating... Sorry to use a whataboutism, but if this is really the reason, then why is the vivaldi-widevine package allowed to exist? That is an *exact* duplicate of chromium-widevine, and has been on AUR for 5 years without getting deleted. Same for qt5-webengine-widevine and qt6-webengine-widevine. >> Supporting evidence: >> - chromium-widevine downloads the entire chrome browser to only >> extract the lib. The widevine package downloads the separately >> packaged lib directly from google. This is much more efficient. > > > The straightforward solution would be to use the widevine source in the > chromium-widevine package, but I doubt the maintainer is willing to do > that. > > In the case the chromium-widevine package would be abandoned, you could > maintain it, but until that moment arrives, I think there's no point in > keeping the duplicated package, only for supporting the unsupported > architectures or to add thirdy part browsers. See vivaldi-widevine, qt5-webengine-widevine and qt6-webengine-widevine mentioned above. Those packages add a whole lot less extras than this package (on x86_64), but somehow they can continue to exist because they probably weren't attracting any attention raised by ARM folks. > Unfortunately after one month of discussion I still cannot find any > reasons to keep this package. Those were two emails. Sorry that I forgot to reply in time. PS: Since this seems to be the end of the line: I really didn't want to bring this up, but I'm really sick and tired of the witch-hunt for ARM-related packages. In my experience it's always the same user (I'm not going to mention the name) that's actively hunting for ARM-related packages to submit deletion requests for. That same person keeps on mentioning that the packages should move to some non-existent ALARM AUR infrastructure. Please also note that ArchlinuxARM is using "Archlinux" as part of its name under license from the ArchLinux project. I've brought this up several times now with Archlinux maintainers: please make up your mind: either you consider ArchlinuxARM to be a sister project and allow it *some* leeway, or you withdraw the license to use the name to make clear that it's completely unrelated. Sorry, I needed to get that out of my system apparently... :-) I'm just getting so damn frustrated by having packages deleted that I'm maintaining with heart and soul, and have poured hours of research into, just because they attract extra attention caused by people using ARM architectures. Cheers, Bart

1 year, 4 months

Re: [PRQ#43405] Deletion Request for electron-xdg-bin

by Marcell Meszaros

Scarlett, Thank you for your feedback. However, let me try to clarify the situation. The XDG Base Directory Specification is a de-facto standard. Arch Linux is a distribution that extensively conforms to this specification throughout a large number of core and extra packages that are part of the commonly used desktop environments. [a] If a package does not respect the configured XDG directories, it should be addressed via bug ticket. For more details, please read the Arch wiki article about the topic. [a] Marcell (MarsSeed) [a]: https://wiki.archlinux.org/title/XDG_Base_Directory On 2 July 2023 16:32:42 GMT+02:00, Scarlett Haxie <administrator(a)hax.ie> wrote: >Marcel, > >The XDG configuration (moving the .pki folder) is not a standard thing and is not a "bug" or a feature request the main repo packages would change, as it's non-standard. > >As a result, this is not a duplicate of the repo's electron package, nor are any of the others you flagged in the past 15 minutes, Please kindly revoke your deletion requests. > >Scarlett. > >On 02/07/2023 15:14, notify(a)aur.archlinux.org wrote: >> MarsSeed [1] filed a deletion request for electron-xdg-bin [2]: >> >> Duplicate of repo 'electron', pkg owner's build. >> >> @noahvogt, please file your xdg configuration patch as part of a bug / >> feature request ticket for the repo package. Don't duplicate it on >> AUR. >> >> Also no one flagged this as out-of-date, nor mentioned it. >> >> As per AUR submission guidelines [a]: >> >> "The submitted PKGBUILDs must not build applications already in any of >> the official binary repositories under any circumstances. Check the >> official package database for the package. If any version of it >> exists, do not submit the package. If the official package is out-of- >> date, flag it as such. If the official package is broken or is lacking >> a feature, then please file a bug report." >> >> [a]: >> https://wiki.archlinux.org/title/AUR_submission_guidelines >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/electron-xdg-bin/

2 years, 3 months

Aur-requests search results for query "moved to [extra]"