February 2018 - Aur-requests - lists.archlinux.org

[aur-requests] [PRQ#10527] Orphan Request for ruby-nokogiri
by notify＠aur.archlinux.org 08 Feb '18

08 Feb '18

trougnouf [1] filed a orphan request for ruby-nokogiri [2]: Flagged out-of-date (2017-06-12), won't build, fix in comments. [1] https://aur.archlinux.org/account/trougnouf/ [2] https://aur.archlinux.org/pkgbase/ruby-nokogiri/

1 1

[aur-requests] [PRQ#10523] Orphan Request for gcsfuse
by notify＠aur.archlinux.org 08 Feb '18

08 Feb '18

aimileus [1] filed a orphan request for gcsfuse [2]: This package is out-of-date for quite some time now. It was also never updated since it was released in 2016. On the other hand, this package actually builds from git so in that sense it's not out of data. Even then, the -git surfix should be added, and the i686 archtecture should be removed. [1] https://aur.archlinux.org/account/aimileus/ [2] https://aur.archlinux.org/pkgbase/gcsfuse/

1 1

[aur-requests] [PRQ#10388] Orphan Request for opensnap
by notify＠aur.archlinux.org 08 Feb '18

08 Feb '18

E5ten [1] filed a orphan request for opensnap [2]: The maintainer has a typo in the dependencies, listing wmctl instead of wmctrl, someone commented about this some time ago, and there was no response, nor has it been fixed. [1] https://aur.archlinux.org/account/E5ten/ [2] https://aur.archlinux.org/pkgbase/opensnap/

1 1

[aur-requests] [PRQ#10522] Deletion Request for paraview
by notify＠aur.archlinux.org 08 Feb '18

08 Feb '18

eolianoe [1] filed a deletion request for paraview [2]: paraview is now in [community] [a] [a] https://www.archlinux.org/packages/community/x86_64/paraview/ [1] https://aur.archlinux.org/account/eolianoe/ [2] https://aur.archlinux.org/pkgbase/paraview/

1 1

Re: [aur-requests] Answer to: [PRQ#10517] Orphan Request for ndi-sdk
by Daniel Bermond 07 Feb '18

07 Feb '18

On 02/07/2018, Eli Schwartz via aur-requests wrote:> I too agree with your reasoning, and in some cases like the proposed > change to actually running the installer.sh feel that this is totally > wrong, serving no purpose except to run an obtuse script rather than > extracting a tarball. > > Moving the headers to /usr/include/ndi-sdk does *not* make a lot of > sense considering that they are extremely unlikely to clash with > anything else, and moving to a subdirectory would cause the Arch Linux > package to require specifying -I/usr/include/ndi-sdk for projects that > need it rather than relying on the global /usr/include path. And there > is no pkg-config file to standardize this... >> See how many repo packages have top-level headers... Thank you Eli for agreeing too. And thank you also for reinforcing my objections against the proposed changes ;) > glibc does not "need" to be a dependency. A majority of packages in the > repos *and* the AUR require a working glibc, but we don't usually list > it as a dependency. glibc is in the base group, and dozens of vital > system components rely on it. If you don't have glibc installed, your > system is so completely and utterly borked, that ndi-sdk will not even > be noticed in the mess. ;) > > That being said, there is certainly no rule against adding it. I > certainly wouldn't, though, just as I don't add dependencies on, say, bash. > > It is really up to the maintainer. I see, and I also agree that adding some dependencies that are in base group is unnecessary. But AUR users sometimes complain about the namcap output when it lists some missing dependencies, or some other namcap errors/warnings. In this ndi-sdk case, namcap tells that 'glibc' is missing, and AUR user 'pschichtel' mentioned "namcap compliance" in the ndi-sdk AUR webpage. People don't realize that a clean namcap output should not be considered a standard in terms of packaging, because many times it gives undesired results. I think that it should be clearly stated on namcap Arch Wiki page, so people will stop to complain about every package that does not give a clean namcap output. It's not the first time that I receive such kind of namcap comment on the AUR packages that I maintain. > Some AUR users are nudniks. Ignore them. We do... Thank you for the advice. I'll try to follow it :) --Daniel M. Bermonde-Mail: danielbermond(a)yahoo.com Em Quarta-feira, 7 de Fevereiro de 2018 14:06, Alad Wenter <alad(a)mailbox.org> escreveu: On Wed, Feb 07, 2018 at 04:00:52PM +0000, Daniel Bermond via aur-requests wrote: > Hi, > I'm the maintainer of AUR package ndi-sdk. This package has received an orphan request in February 7, 2018 and I would like to defend myself against this orphan request. > Yes, this is the correct place to answer on orphan requests. Anyway I agree with your reasoning so I've rejected the request. Alad

1 0

[aur-requests] [PRQ#10521] Orphan Request for chrome-remote-desktop
by notify＠aur.archlinux.org 07 Feb '18

07 Feb '18

klepz [1] filed a orphan request for chrome-remote-desktop [2]: The package maintainer does not appear to be updating, I would like to own this package. [1] https://aur.archlinux.org/account/klepz/ [2] https://aur.archlinux.org/pkgbase/chrome-remote-desktop/

1 1

[aur-requests] Answer to: [PRQ#10517] Orphan Request for ndi-sdk
by Daniel Bermond 07 Feb '18

07 Feb '18

Hi, I'm the maintainer of AUR package ndi-sdk. This package has received an orphan request in February 7, 2018 and I would like to defend myself against this orphan request. I'm not sure if this list is the right place to defend against an orphan request. I don't even know it there is a way to cancel an orphan request, so I'm writing here. I express my apologies beforehand if this is not the right place to defend against the orphan request. Please guide me to the correct place if here is not the right place for this. I totally disagree with this orphan request. According to the AUR requests page, a package should be orphaned if it needs maintainer action, or if the maintainer is MIA. Being such, I have to state some facts: 1) ndi-sdk package is _not_ out-of-date. 2) ndi-sdk package is _not_ broken. It is building and working fine. 3) I'm not missed. I'm here. The AUR user named 'pschichtel' have posted a comment on the ndi-sdk package webpage _nine_days_ ago, and I still have not answered it yet, mostly because it's just a suggestion about changes that he likes to be made on the PKGBUILD. I have not yet got the time to analyse everything, because it looks likes to be a total rewrite of the PKGBUILD. I don't even think that I should answer such posts because I, as the maintainer, don't agree with many of his proposed changes that I could gather at a quick and first look. He also have emailed me, but only now I can see that his e-mail got into the spambox, so I could still not answer yet. His e-mail is from February 3rd, 2018. Of course the PKGBUILD can be improved, like adding a 'glibc' dependency and other things. But I don't think that this should be sufficient to raise an orphan request. I don't think either that an unanswered post from _nine_days_ ago on the package webpage and an unanswered e-mail from _four_days_ ago should be sufficient for accepting an orphan request. So, I gently ask the AUR admins to reject this orphan request. Best regards, --Daniel M. Bermonde-Mail: danielbermond(a)yahoo.com

3 2

[aur-requests] [PRQ#10299] Deletion Request for hakuneko
by notify＠aur.archlinux.org 07 Feb '18

07 Feb '18

berserkingyadis [1] filed a deletion request for hakuneko [2]: this project has been abandoned by the creator src: https://sourceforge.net/projects/legacy.hakuneko.p/files/ there is a "new" hakuneko, which already has a package https://aur.archlinux.org/packages/hakuneko-desktop [1] https://aur.archlinux.org/account/berserkingyadis/ [2] https://aur.archlinux.org/pkgbase/hakuneko/

1 1

[aur-requests] [PRQ#10387] Orphan Request for gpredict
by notify＠aur.archlinux.org 07 Feb '18

07 Feb '18

virtualdxs [1] filed a orphan request for gpredict [2]: The package is very far out of date, and I'd like to become the maintainer and update it. [1] https://aur.archlinux.org/account/virtualdxs/ [2] https://aur.archlinux.org/pkgbase/gpredict/

1 1

[aur-requests] [PRQ#10382] Orphan Request for debian-keyring
by notify＠aur.archlinux.org 07 Feb '18

07 Feb '18

buzo [1] filed a orphan request for debian-keyring [2]: This package is outdated for more than a month and I have a (straightforward) fix for the PKGBUILD. I'd also be willing to adopt the package, if needed. [1] https://aur.archlinux.org/account/buzo/ [2] https://aur.archlinux.org/pkgbase/debian-keyring/

1 1