Re: [PRQ#40336] Merge Request for php-stan
Max 於 2023年2月26日 週日 上午12:38寫道： > > Maintainer of the php-stan [1] package here. > > I once created a comment on the phpstan package [2], > but never received any feedback. I agree that the packge > should be named phpstan. But preferably even phpstan-bin, > as it is not built from the source. > > I could create a new package named phpstan-bin and both > phpstan and php-stan could be merged into that package. > > [1] https://aur.archlinux.org/pkgbase/php-stan/ > [2] https://aur.archlinux.org/packages/phpstan#comment-791729 > > On Sat, Feb 25, 2023 at 5:18 PM wrote: > > > > yan12125 [1] filed a request to merge php-stan [2] into phpstan [3]: > > > > phpstan appears the official name. It appears as the domain name, the > > logo, the github repo name, the executable name, ... And I find only > > few mentions about "php-stan" on Google. > > > > [1] https://aur.archlinux.org/account/yan12125/ > > [2] https://aur.archlinux.org/pkgbase/php-stan/ > > [3] https://aur.archlinux.org/pkgbase/phpstan/ Thanks, a good point about -bin. I will drop the current request and issue new ones. Cheers, Chih-Hsuan Yen (yan12125)
Re: [PRQ#47235] Merge Request for python-tts Rejected
Marcell Meszaros 於 2023年12月11日 週一 下午8:18寫道： > > >Upstream describes itself as "a deep learning toolkit for Text-to- > >Speech, battle-tested in research and production" [1], so this > >software is apparently designed as a Python module rather than a CLI > >application. As a result, python-tts is a better package name per > >Python packaging guidelines > > Nevertheless, this is an application too. > > >From ArchWiki Python package guidelines (*emphasis* mine): > " > For Python 3 library modules, use python-modulename. Also use the prefix if > the package provides a program that is strongly coupled to the Python > ecosystem (e.g. pip or tox). For other *applications*, use only the program > name. > " > Most likely this statement is for software that is primarily designed as an application. I may misunderstood the intention of upstream developers, though. If that's the case, please resubmit the merge request, thanks. Regards, Chih-Hsuan Yen (yan12125) > Therefore the correct assessment in my view is still to name the package > 'tts' and add provides & conflicts for 'python-tts'. > > On 11 December 2023 12:24:59 GMT+01:00, notify(a)aur.archlinux.org wrote: > >Request #47235 has been Rejected by yan12125 [1]: > > > >Upstream describes itself as "a deep learning toolkit for Text-to- > >Speech, battle-tested in research and production" [1], so this > >software is apparently designed as a Python module rather than a CLI > >application. As a result, python-tts is a better package name per > >Python packaging guidelines [2]. > > > >[1] https://github.com/coqui-ai/TTS > >[2] https://wiki.archlinux.org/title/Python_package_guidelines > > > >[1] https://aur.archlinux.org/account/yan12125/
Re: [PRQ#42786] Deletion Request for autopsy-bin Rejected
Marcell Meszaros 於 2023年7月30日 週日 下午6:20寫道： > > @yan12125, why did you reject the deletion request for this duplicate? > > AUR/autopsy also uses the precompiled Java bytecode as source. > > So the two packages are truly duplicates, the only difference is that > autopsy-bin is 1 year older and flagged OOD for that period. > > On 30 July 2023 11:05:20 GMT+02:00, not...@aur.archlinux.org wrote: > >Request #42786 has been Rejected by yan12125 [1]: > > > >> This is a java application so the > >suffix '-bin' is not necessary anyway. > > > >Java packages can be either built from sources or binaries as well. > > > >[1] https://aur.archlinux.org/account/yan12125/ autopsy-bin is a better package name for a package built from binaries. Therefore, orphaning and updating autospy-bin is better than deleting autospy-bin. After that, autospy can be merged into autospy-bin in case it is not changed to be built from sources. Best, Chih-Hsuan Yen (yan12125)
Re: [PRQ#65187] Deletion Request for xfwm4-theme-breeze
Chih-Hsuan Yen 於 2024年11月10日 週日 下午7:00寫道： > > 於 2024年11月2日 週六 下午5:09寫道： > > > > MarsSeed [1] filed a deletion request for xfwm4-theme-breeze [2]: > > > > EOL Gtk2 based Xfwm4 theme from 2015. > > Not compatible with the current, Gtk3 based Xfwm4. > > > > MarsSeed: could you double-check? xfwm4-theme-breeze still works fine > with xfwm4 for me. > I restored https://aur.archlinux.org/pkgbase/xfwm4-theme-breeze/. Please submit another request with concrete evidence if this package is really broken. > > [1] https://aur.archlinux.org/account/MarsSeed/ > > [2] https://aur.archlinux.org/pkgbase/xfwm4-theme-breeze/
Re: [PRQ#65187] Deletion Request for xfwm4-theme-breeze
於 2024年11月2日 週六 下午5:09寫道： > > MarsSeed [1] filed a deletion request for xfwm4-theme-breeze [2]: > > EOL Gtk2 based Xfwm4 theme from 2015. > Not compatible with the current, Gtk3 based Xfwm4. > MarsSeed: could you double-check? xfwm4-theme-breeze still works fine with xfwm4 for me. > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/xfwm4-theme-breeze/
Re: [aur-requests] [PRQ#33687] Orphan Request for python-pygraphviz Rejected
> Il 02/04/22 15:01, notify--- via aur-requests ha scritto: > > Request #33687 has been Rejected by yan12125 [1]: > > > > The package is updated by a co-maintainer. > > > > [1] https://aur.archlinux.org/account/yan12125/ > > The pkgbuild has been updated by one of the other 2 co-maintainers but > the maintainer asked for deleting this pkgbuild without a valid reason > and without removing themself as maintainer, so remving alienzj would > have been ok imho Orphaning such a maintained package does not really make sense unless a co-maintainer wants to become the maintainer, and I do not see such an intention for now. signature.asc Description: PGP signature
Re: [aur-requests] [PRQ#35142] Deletion Request for tensorflow_datasets
Minion Jim 於 2022年6月9日 週四 上午12:44寫道： > > I agree with this request. I decided for simplicity, I would simply > adopt the package rather than rename it, but since > `python-tensorflow-datasets` has been created, it makes sense to remove > this package. Thanks! I will accept both deletion requests.
Re: [aur-requests] [PRQ#26744] Deletion Request for octoprint-venv
On Tue Jun 29 09:15:31 UTC 2021, Jake wrote: > If you dislike the general approach of using a venv then just > contribute/patch the already existing 'octoprint' (no suffix) package to > remove the venv there. Keep in mind that this would break often on > dependency updates and therefore will be a lot of patch work. I have > tried it for a while and it was just not feasible... Sorry I missed this message and hit the deletion button too early. I first restore the package on AUR. Regarding packaging difficulties - I understand your situaltion as I have met several upstream developers that don't care about the latest dependencies at all. Here are some possible tricks that come to my mind: * Remove upper bounds of dependencies from setup.py. For example, use a sed command to do that like python-moto [1] * If API changes in dependencies are too complex to have a fix, create a package with an older version. For example, the recent python-sqlalchemy1.3 [2] for packages that don't support sqlalchemy 1.4. Have you ever tried those tricks? They are not ideal solutions, either, but may help on getting away from venv. [1] https://github.com/archlinux/svntogit-community/blob/6d2df38acf21085e601e02bfc029c77d8c485285/trunk/PKGBUILD#L49 [2] https://archlinux.org/packages/community-staging/x86_64/python-sqlalchemy1.3/ Regards, Chih-Hsuan Yen signature.asc Description: PGP signature
