Re: [aur-general] Spring cleaning (moving orphaned packages from [community] to AUR)
On 04 Mar 2020, at 2:16 pm -0800, Yardena Cohen via aur-general wrote: > On Tue, Feb 25, 2020 at 7:23 AM Alexander F Rødseth via aur-general > wrote: > > privoxy - A web proxy with advanced filtering capabilities. > I'd hope that privoxy doesn't get dropped - it's necessary for using > Tor in most cases https://wiki.archlinux.org/index.php/Privoxy It got adopted the day the message went out, I believe. Note the new maintainer on [its page][1]. For future reference, you can always search for packages using Arch's [package search][2]. [1]: https://www.archlinux.org/packages/community/x86_64/privoxy/ [2]: https://www.archlinux.org/packages/ signature.asc Description: PGP signature
Re: [aur-general] TU resignation - Lukas Jirkovsky (stativ)
On 11 Oct 2019, at 6:32 pm +0200, Morten Linderud via aur-general wrote: > > So Long, and Thanks for All the Fish Thanks for your work all these years! > Added a list of packages maintained solely by stativ. Please adopt as people > see fit :) > λ ~ » /usr/share/archlinux/contrib/package/co-maintainers -m stativ > ttf-gentium Adopted. Cheers, Ivy
Re: [aur-general] TU application: Daurnimator
On 11 Dec 2018, at 12:10 pm -0800, Daurnimator wrote:
> On Tue, 11 Dec 2018 at 12:04, Robin Broda via aur-general
> wrote:
> > On 12/11/18 9:00 PM, Daurnimator wrote:
> > > On Tue, 11 Dec 2018 at 11:45, Alad Wenter via aur-general
> > > wrote:
> > >> 2. You have some AUR packages for LUA modules of your own making, yet
> > >> they hardcode gcc lines instead of using a Makefile. [1] (At least they
> > >> respect $CFLAGS and $LDFLAGS, I guess.) Why?
> > > The upstream packages do not ship a makefile; they "officially" only
> > > support luarocks for building.
> > You are upstream, you have the power to make a change for the better
> The problem is that there is no nice cross-platform makefile structure
> suitable for lua libraries.
> Each operating system/distro calls the lua shared library something
> different, they all have their own set of required and conflicting
> flags, they all have differing install locations and search paths!
Yikes!
One ugly but workable solution could be to conditionally set variables
in a Makefile. For instance:
ifeq ($(OS),Windows_NT) # for Windows versions >= NT
LUA := C:\Winders\Path\To\Lua.whatever
else
UNAME := $(shell uname -s)
ifeq ($(UNAME),Linux)
LUA := ...
endif
...
endif
Granted, this likely duplicates some of the magic luarocks is doing,
but it would make things simpler for packaging.
Come to think of it, that seems like the sort of thing that could be
done once as boilerplate in, e.g., lua.mk, which you and other
luarines (lua-ites? luans? lua-ers?) could then include in future
Makefiles.
Just spitballing here; lua packaging is weird (-: .
Cheers,
Ivy ("escondida")
signature.asc
Description: PGP signature
Re: [aur-general] TU application: Daurnimator
Thanks for the application, Daurnimator!
Looking at arcan, why do you break it up into so many different
sub-packages? I understand that they provide different tools, but
typically Arch just packages toolsuites together unless there's a
compelling reason to separate some of them.
Also, libarena has https sources/url available.
Cheers,
Ivy ("escondida")
signature.asc
Description: PGP signature
[aur-general] TU Application: Daniel M. Capella
Hello, everyone!
The results are in! Congratulations, Daniel! Welcome to the team.
Stats:
34 Yes
6 No
7 Abstain
Cheers,
Ivy ("escondida")
P.S.: Please forgive the broken threading; I foolishly cleaned out too
much of my inbox last week!
signature.asc
Description: PGP signature
Re: [aur-general] TU Application: Daniel M. Capella
The two week discussion period is over! Let the voting period begin! https://aur.archlinux.org/tu/?id=114 signature.asc Description: PGP signature
Re: [aur-general] TU Application: Daniel M. Capella
I confirm my sponsorship; let the games (or discussion, I guess)
begin!
iff ("escondida")
signature.asc
Description: PGP signature
Re: [aur-general] On TU application, TU participation and community/ package quality
Santiago, thanks for writing up the discussion to date! On 11 Nov 2018, at 1:29 pm -0500, Santiago Torres-Arias via aur-general wrote: > 1. Add a council of TU's to introduce oversight on the whole voting >process > Creating a council of TUs who, by means of experience and involvement, > make sure the approval of new TU's is properly reviewed. As such, this > council will be in charge of voting in and/or sponsoring a new TU > applicant. > This raises questions about the horizontal power structure of the TU > community. The consequences of bringing a hierarchy like this need to be > discussed, as more than one TU is concerned of the implications of this > model. I'm pretty new to the whole TU thing, but I'm a little leery of this idea for a few reasons. As you mention, there are power dynamics at play once you start getting into things like this. Perhaps more importantly to the discussion at hand, I would also argue that such a set-up would do little to take the load off of the handful of high-participation TUs; if anything, I can see it *adding* to their load by formalizing their ad-hoc status. > 2. Increase the minimum number of sponsors per application This could be helpful, particularly when it comes to giving advice to newly-appointed TUs. > However, one question raised during the discussion is whether this model > is enough to warrant the goals outlined above. Namely, this measure > doesn't seem to tackle the lack of participation of the broader TU > community when reviewing new TU applications. Granted. With any luck, this very discussion will help *some* with that issue, but if we go with proposal 2, perhaps participation issues could be handled as a separate problem altogether. I know that, personally, I almost never participate in new candidate discussions simply because I don't feel I have anything to add. > 3. Create a working group of TU's to review recent applications and >warn TU's that do *not* appear to be performing their duties >appropriately > Finally, a third proposal (and the one I'm championing) is to generate > an elected organism within the TU community to overlook the performance > of Trusted Users on the duties they agreed to fulfill. This oversight > committee would track the activities of individual TUs and ensure that > they are in fact participating in reviews, submitting proper > high-quality PKGBUILDS, and moving packages to and from the AUR when the > package's popularity changes. I'm pretty conflicted about this idea, to be honest. Although I'm all for having some sort of oversight, the cynic in me forsees all kinds of problems even if you assume that all parties involved are acting in good faith (which I do choose to assume here). Even given the existence of TU guidelines, we would probably need to set up some very specific, enforceable rules in order for this to be at all workable. Would there need to be a participation quota? How strict do we really want to be about package popularity? Whose idea of "high-quality" are we using? Unless there are definite answers, we're right back where we started, with a set of guidelines to be played by ear--but now with the added overhead of a subcommittee structure. Personally, I'm inclined toward simply increasing the number of sponsors and encouraging sponsors to help their candidates learn the ropes of proper Trusted Using. If nonparticipation continues to be a problem, that can be a separate discussion. Cheers, Ivy signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 07 Nov 2018, at 5:41 pm -0700, Brett Cornwall via aur-general wrote: > On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: > > - don't think pkgdesc should ever end with a dot > The descriptions are often sentences, so would it not reason to end them > with a period? In the case of actual sentences, it's just convention to be consistent with the packages whose descriptions are sentence fragments. It's a bit arbitrary, granted. > > - not a big fan of fiddling with PKGEXT even if its "just the AUR" but > > well > > For a package destined for the repositories I would not fiddle and endeavor > to reverse such fiddling; however, the compression time for large games is > enormous only to decompress right after. Should it, for the sake of > correct-ness, be reversed even for the packages doomed forever to live in > the AUR? It's just not the prerogative of the AUR contributor to make that decision for the end-user who's going to be building the package. They can very easily configure their own makepkg.conf to use uncompressed tarballs if they so desire. Basically, a PKGBUILD shouldn't override makepkg.conf unless there's a very good reason. Cheers, Ivy signature.asc Description: PGP signature
Re: [aur-general] PKGBUILD(s) Review
On 22 Feb 2018, at 7:45 +0530, Ankit R Gadiya wrote:
> Hi everyone,
>
> I added two new PKGBUILD(s) today in the AUR, both are plugins for vim.
> Any advice, suggestions or feedback will be greatly appreciated.
> And if anybody would like the *-git versions of these I will be more
> then happy to add them as well.
>
> 1. ranger-vim: https://aur.archlinux.org/packages/ranger-vim/
> 2. tcomment-vim: https://aur.archlinux.org/packages/tcomment-vim/
>
> install -Dm755 "${srcdir}/${pkgname/-/_}-${pkgver}/plugin/tcomment.vim"
> \
> "${pkgdir}/usr/share/vim/vimfiles/plugin/tcomment.vim"
> install -Dm755 "${srcdir}/${pkgname/-/_}-${pkgver}/doc/tcomment.txt" \
> "${pkgdir}/usr/share/vim/vimfiles/doc/tcomment.txt"
> install -Dm755
> "${srcdir}/${pkgname/-/_}-${pkgver}/autoload/tcomment.vim" \
> "${pkgdir}/usr/share/vim/vimfiles/autoload/tcomment.vim"
Normally I wouldn't actually comment on this niggle, but I'd argue
that it's often best to optimize for legibility.
Now, there are definitely religious differences on this point. The
names of the packages are almost certainly not going to change (unlike
the versions), so personally, I'd say that "tcomment-vim" is going to
be immediately clearer to the reader than $pkgname, and "tcomment_vim"
is *definitely* going to be clearer than "${pkgname/-/_}" (and the use
of the shell replacement is what inspired me to make this comment).
Granted, it's not going to be *difficult* to figure out, but there you
go. Anything else others already mentioned.
Cheers,
iff
Re: [aur-general] TU application: Ivy Foster
On 10 Feb 2018, at 1:02 +0100, Alad Wenter via aur-general wrote: > the proposal has been accepted. Congratulations! Awesome! Thanks, y'all. Ivy signature.asc Description: PGP signature
Re: [aur-general] TU application: Ivy Foster
On 01 Feb 2018, at 8:29 +0100, Levente Polyak via aur-general wrote: > On January 30, 2018 11:37:42 PM GMT+01:00, Ivy Foster > wrote: > >I'll have some time free tomorrow to get you a proper answer and/or > >fix; for now, I'm just letting you know I got your email! > Hey, any news from respecting LDFLAGS and if needed just purge parts of it? > I'm specially interested in seeing full relro. Hey, Levente. Sorry for the delay! For cgo, since upstream pulled in the patches I submitted, LDFLAGS are properly picked up and we have full relro. libbulletml was a bit tougher. I wound up throwing out Debian's patches to upstream's Makefile and just rewriting the Makefile from scratch. Hopefully either Debian or the dev will be interested in accepting the new Makefile; until word comes back, it's [in the AUR git repo][1]. This also grants full relro. I've yet to run checksec on my other packages, but intend to do so. I'm not sure yet what to do about some of its feedback, notably thinking that some binaries aren't ELF files (so no PIE feedback given) or the number of unfortified...things. Thanks again for your feedback! Ivy [1]: https://aur.archlinux.org/cgit/aur.git/tree/?h=libbulletml signature.asc Description: PGP signature
Re: [aur-general] TU application: Ivy Foster
On 28 Jan 2018, at 9:33 +0100, Levente Polyak via aur-general wrote: > Hey, good luck and such Thanks! > Just noticed [some interesting points] I'll have some time free tomorrow to get you a proper answer and/or fix; for now, I'm just letting you know I got your email! Thanks, Ivy
Re: [aur-general] TU application: Ivy Foster
On 27 Jan 2018, at 10:40 +0100, Christian Rebischke via aur-general wrote: > On Fri, Jan 26, 2018 at 03:23:08PM -0600, Ivy Foster wrote: > Hello Ivy, > Do you plan to adopt some orphans as well? Definitely! Quickly scanning through the list, a few stand out to me...though they generally don't look as though they need updates right away. - bmake - cd-discid (if I were to crab this one, I'd probably also take cddb_get, even though I've had little luck with cddb results) - ispell - libcdaudio - unicode-character-database Beyond that, I'd say "sure, if it looks interesting or necessary" and "I can at least update and then re-orphan this thing I don't use". iff
[aur-general] TU application: Ivy Foster
On 27 Jan 2018, at 9:39 +0100, Pierre Neidhardt, Andrew Crerar, and Johannes Löthberg wrote: > [some very nice things] Thanks!
Re: [aur-general] TU application: Ivy Foster
On 26 Jan 2018, at 4:35 -0500, Eli Schwartz via aur-general wrote: > On 01/26/2018 04:23 PM, Ivy Foster wrote: > > I'm writing to apply to be a TU, and Alad Wenter has kindly agreed to > > be my sponsor. > It is great to see you take the plunge, I wish you the best of luck! Thanks! > > Arch has always been a rewarding community to contribute to, and I > > figure that maintaining some packages and generally helping out could > > be a good way to contribute a bit more. > > > > If accepted to be a TU, my plan of action is as follows: > > 1. Go mad with power^U > > 1. Bring a handful of packages into [community] (see below) > > 2. Help out with rebuilds and package updates where that does not > > involve stepping on toes > > 3. Continue to submit occasional patches to Arch projects > > 4. Help with to-do lists. [...] > Sounds like a (wo)man after my own heart! Woman, and glad to hear it! > This reminds me I still have so much to do... like all that https/gpg stuff. There's always more to do, I guess. > > Thanks for your consideration, and I'm of course happy to answer > > questions and address critiques. > But overall, quite good! Thanks! > > - ledger > > This program is super useful, and I doubt I'm the only one who > > dreads every boost update because this takes so long to build! > Lukas has beaten you to it: https://packages.archlinux.org/ledger I replied to this elsewhere already, but that's great news (-: . In related news, I've [poked upstream][1] to see about a new release, since there's been a year's worth of bugfixes! They're into it. # Critiques & Responses > We discussed this on IRC already, I'll have to check and see how you've > adapted to my suggestions. I've addressed most of them; see responses inline. Of course, onlookers should judge each fix to make sure it's not a "fix" instead. ## cgo-git > 2018-01-25 07:07:51 PMguysI noticed something immediately, > cgo-git has > a custom:cgo-git license, but it is really an ISC license. > 2018-01-25 07:08:15 PMguysAnd it installs the whole source code in > /usr/share/licenses/ instead of using sed to extract it or something. :p > 2018-01-25 07:09:25 PMguysI'd just extract the first few lines > using > sed, until I hit the first */ and call it a day I've changed the license to ISC and used sed to extract the license from the source. I've also [submitted a patch upstream][2] creating a separate LICENSE file. > 2018-01-25 07:11:25 PMguysAlso, the upstream Makefile is terrible > and > should use CFLAGS properly :p > 2018-01-25 07:12:27 PMguysI want pull requests to fix this :p [Pull request submitted][3]. > 2018-01-25 07:14:28 PMguysfist, should be upgraded to use HTTPS > since > their website upgrades you anyway [Done][4]. ## frotz-dumb-git / frotz-ncurses-git > 2018-01-25 07:27:55 PMguysfrotz-git conflicts and *replaces* > frotz, > which is wrong, it should provide it instead > 2018-01-25 07:28:23 PMguysreplaces means that if you pacman -Syu > and > find it in a repo, it gets synced as a replacement for what you > currently have... > 2018-01-25 07:29:11 PMguysI can hardly read the sed line you use > in > pkgver() > 2018-01-25 07:29:22 PMguyssed 's,-\(.*\)-,.r\1.,' > 2018-01-25 07:29:30 PMguyswrong place to use , as separators! > 2018-01-25 07:33:03 PMguysBut anyway, to modify 2.44-196-gf3ceac9 > could just use the standard sed line from the wiki page > 2018-01-25 07:34:05 PMescondida that one *I* can hardly read (-: > 2018-01-25 07:35:48 PMguysUse of sed to modify more than three > things > in prepare should be strictly prohibited; use a patch file [All fixed][5]. I still refuse to use the sed line from the wiki page, because I'm a big weirdo. ## libbulletml & rrootage > 2018-01-25 07:39:48 PMguys> # upstream does not provide checksums, > though Debian does for their patches > 2018-01-25 07:40:04 PMguysThis is not a reason to disable checks > for > download errors. I've [added checksums][6], along with a note not to place too much trust in them since they're mine and not the developer's. > 2018-01-25 07:41:09 PMguysWhy does libbulletml.so need to modify > CFLAGS CXXFLAGS :( > 2018-01-25 07:41:21 PMguysAnd why does it overwrite LDFLAGS, > instead? > 2018-01-25 07:41:41 PMguysDoes it derp on the LDFLAGS from > makepkg.conf? > 2018-01-25 07:42:17 PMguysWhy does it crea
Re: [aur-general] TU application: Ivy Foster
On 26 Jan 2018, at 10:31 +0100, Alad Wenter via aur-general wrote: > Note: If possible please add a short reply with a GPG signature. My mistake! Here's my official, signed reply. Eli Schwartz wrote: > Lukas has beaten you to it: https://packages.archlinux.org/ledger That is excellent news! Thanks, Ivy signature.asc Description: PGP signature
[aur-general] TU application: Ivy Foster
Hi, folks, I'm writing to apply to be a TU, and Alad Wenter has kindly agreed to be my sponsor. I've been an Arch user for the last 10 years or so. Some of you may know me from IRC or the forums, where I use the nick escondida. Lately, I've been much less active on IRC, but have contributed a handful of patches to pacman. I also maintain [a few buildscripts][1] in the AUR. Arch has always been a rewarding community to contribute to, and I figure that maintaining some packages and generally helping out could be a good way to contribute a bit more. If accepted to be a TU, my plan of action is as follows: 1. Go mad with power^U 1. Bring a handful of packages into [community] (see below) 2. Help out with rebuilds and package updates where that does not involve stepping on toes 3. Continue to submit occasional patches to Arch projects 4. Help with to-do lists. Off the top of my head, taking a quick look at current to-do lists with actual outstanding items: https://www.archlinux.org/todo/packages-with-out-of-repositories-dependencies/ I'd be interested both in simply weeding out those with inappropriate deps and in bringing in deps I'd consider actually useful, such as tcllib for tcl-remind. https://www.archlinux.org/todo/source-retirement/ https://www.archlinux.org/todo/codegooglecom-retirement/ I wouldn't mind tracking down lost sources. Thanks for your consideration, and I'm of course happy to answer questions and address critiques. Cheers, Ivy "escondida" Foster # Packages If I'm accepted, there are a handful of packages I already have in mind to bring to the repos: - [bemenu][2] Though dmenu is already available, bemenu is a solid alternative for X, Wayland or terminals. - [farbfeld][3] An oddball but interesting new image format - [frotz][4] I don't know about you guys, but I think that text adventures are positively xyzzy. - [ledger][5] This program is super useful, and I doubt I'm the only one who dreads every boost update because this takes so long to build! - [muttprint][6] I don't always print emails, but when I do, I use muttprint. - [opendoas][7] OpenBSD's much simpler alternative to sudo is now available for Linux. - [physlock][8] A tty screen locker - [sndio][9] OpenBSD's excellent and simple sound system is now available as a userspace daemon for Linux, and a surprising number of things can build against it easily. Note that if I did bring this in, I wouldn't be including my very basic XDG basedir patch (see AUR scripts). I'm going to try and submit a better one upstream, and if that fails, then...oh, well, I guess. - [t-prot][10] It's just a simple script, but as a mutt user, it comes very much in handy for making many emails more legible. - [translate-shell][11] Very useful for simplifying or scripting translation tasks (not that you should be counting on google translate to handle anything longer than a few words, but still) - [xurls][12] Saves you the trouble of parsing strings to find links # Links [1]: https://aur.archlinux.org/packages/?SeB=m&K=escondida [2]: https://github.com/Cloudef/bemenu [3]: https://tools.suckless.org/farbfeld/ [4]: http://frotz.sourceforge.net/ [5]: https://www.ledger-cli.org [6]: http://muttprint.sourceforge.net/ [7]: https://github.com/Duncaen/OpenDoas [8]: https://github.com/muennich/physlock [9]: http://www.sndio.org/ [10]: http://www.escape.de/~tolot/mutt/ [11]: https://www.soimort.org/translate-shell/ [12]: https://github.com/mvdan/xurls
Re: [aur-general] VCS package guidelines
Eli Schwartz via aur-general wrote: > On 03/08/2017 04:06 PM, Ralf Mardorf wrote: > > On Wed, 8 Mar 2017 18:00:52 -0300, Rafael Fontenelle wrote: > >> 2017-03-08 17:53 GMT-03:00 Ralf Mardorf : > >>> my understanding is, that if possible, it should look like this > >>> 1.2.r3.gabcdef7 > >>> and not alternatively > >>> 1.2_r3_gabcdef7 > >>> or > >>> 1.2_3_gabcdef7 > In other words, maintainers of any stripe are absolute dictators over > their package, as long as they don't commit offenses against the AUR > package-hosting service itself, which would be grounds for deleting the > package, and they keep their package up to date with upstream releases, > which failure to do so is grounds for package orphaning. You (rhet.) can > (and often do) highly disapprove of their choices, but at the end of the > day, they cannot be *forced* to do anything. Of course, you also can't be forced to install a packaging whose versioning or build options you dislike. PKGBUILDs are trivial to edit to taste. I recognize that the AUR ML is a slightly heretical place to suggest this, but...the AUR is not the end-all-be-all of packaging scripts. If you don't like what you see there, write your own or edit an existing one. It'll take you under five minutes if you start from scratch. In short, if you don't like what you see on the AUR and it's not actually harmful, ignore it. You'll be happier you did. iff
Re: [aur-general] Deletion of orphaned packages on AUR4
On 11 Aug 2015, at 3:48 pm +0200, Johannes Dewender wrote: > [snip] > I uploaded both to AUR3 and also to AUR4. > I maintain the free branch, because I think this is the better variant. > Having the original on AUR would be good, so I also updloaded these, but > I personally don't want to maintain these. > There are however some users that still want to use the original. > There aren't many changes either, since the original doesn't have > releases often. > (the free branch has lots of releases) If and only if there is somebody who "still wants to use the original," they'll upload and maintain a PKGBUILD themselves. So it is with any package. Remember, Arch assumes a baseline of competence--or at least willingness to read--on the part of the user, and Arch's packaging tools are dead simple if you actually bother to learn them. There's no need to upload scripts to the AUR on behalf of some nebulous concept of the average user, because the average Arch user can do it themselves if they want to. Have some faith in your fellow users, and let's all work to make the new AUR less of a horrible mess than the old one. iff
Re: [aur-general] [Deletion request] cl-asdf-install
Chris Brannon wrote: > joyfulgirl wrote: > > [cl-asdf-install][1] is now included by default in the [cl-asdf][2] > > package, > 'tis a goner, as of now. Great, thanks!
Re: [aur-general] The search engine needs improvements
On 10 Jan 2009, at 3:50 pm -0800, Olivier Duclos wrote: > Le Sat, 10 Jan 2009 22:55:39 +0100, Xavier a écrit: > > But then again, rar is probably a corner case. I have personally never ran > > into that problem in all the searches I did on AUR so it is probably not > > a big deal :) > I think it would be a great new feature, but still I think that if we have an > exact match, it should be shown first. > I've quickly modified Find.php to do that. At line 261, I changed the if block > to : > [SNIP] > Of course, this only works if $pattern correspond exactly to what the user has > typed, which I am absolutely not sure. Anyway, don't you think it's a good > idea ? So this is probably a completely impractical idea, but what about adding some sort of rudimentary regexp search? Or at least, say, something that would recognize "^" as the beginning of the package name and "$" as the end? Again, I don't know how well this would work, but it's just a thought. Ivy P.S.: Should this be Cc'd to aur-dev? -- If I Ever Become An Evil Villainess... 27. I will never build only one of anything important. All important systems will have redundant control panels and power supplies. For the same reason I will always carry at least two fully loaded weapons at all times. pgpKJIHhDdACM.pgp Description: PGP signature
Re: [aur-general] Official discussion period - Rules governing packages entering [community]
Hi, all, I generally just lurk on this list (as I'm not a TU), but figured I might throw in a couple of cents to this discussion, since there's some talk about statistics, and I have a strong statistical background. Oh, and as it turns out, "a few cents" ends up being something like a dollar. Sorry for the long post, but I'm trying to be thorough. Some of the points that have already been made: (Yes, everybody hates a recap. Deal.) - The current votes system is insufficient as a valid means of determining how many people *really* use a package, because not all users vote. - pkgstats hasn't been around long enough to have generated as much information as folks would like. (And, again, not everybody has installed/used it). - A system for reliably working out what packages have a sufficiently large user base in Arch to justify inclusion in [community] would be a very nice thing to have. My thought is basically that the best way to get decent usage stats for a given package is to implement a pkg-download counter (yes, I know this has been suggested). Unfortunately, this raises some technical issues. Particularly (read: off the top of my head), we'd need a mechanism to account for fringe cases such as people who, say, accidentally remove or break a PKGBUILD and re-download five minutes later, and the (probably/hopefully much more rare) people who would repeatedly download a PKGBUILD in order to artificially inflate its usage statistics. These could probably be taken care of with, say, an IP-address recorder (but that of course raises privacy issues of its own) or requiring users to login in order to download (which I *don't* think is a good idea; it has wa-a-a-a-ay too many obvious drawbacks). It would also be useful not to double-count people who are merely updating to a new version, and to have some means of keeping track of people who have *removed* packages. Pkgstats is a good start in the direction of keeping reliable statistics. Some ideas for making that more prevalent are: - Including a new, well-publicized (so people know they can turn it off) function in pacman that would (optionally, default=yes) to automagically send in installed/removed pkgs (and I suppose a complete list the first time it's run) to something like Debian's popularity-contest server. - Supplementing pkgstats data, where lacking, with data from Debian's popularity-contest server. - Adding a cronjob for pkgstats (again, enabled by default). - Adding a feature to pkgstats that would also *save* the full list it has sent in (preferably to a compressed file, but whatever), and then next time it's run, check against the saved list--packages that have been removed are removed from this master list, and packages that have been added are, well, added to the list. Something like a diff would then be sent in. - Adding pkgstats to the install CD as an optional, but useful, package. So. That's all I can think of on this for now, but if folks would like statistics advice, I'm on this and a couple arch lists, and feel free to CC me on the email or whatever just to get my attention. If someone has specific questions about something or about something I said here, ask! And I'd be glad to help with implementing...whatever gets decided. Thanks for reading this far! Ivy P.S.: For what it's worth, I agree that the actual vote should be tabled until there are one or more solid, researched proposals (which needn't take more than a week or two!). (And not to downplay the actual suggestion in question!) And I'd be glad to help out with that, too, though again I'm not a TU. (-: -- If I Ever Become An Evil Villainess... 46. If an advisor says to me "My liege, the heroine is but one person. What can one person possibly do?" I will reply "This," and kill the advisor. pgpp0VPzww7pG.pgp Description: PGP signature
Re: [aur-general] orphans in community
On 02 May 2008, at 2:20 pm +0200, Firmicus wrote: > > I was thinking of having an AUR cleanup day. I tend notice a lot > > of packages that have been renames or obsoleted by another package > > and left in the AUR. Not necessarily orphans either. If we do > > have an AUR cleanup day, we should open a thread on the forums > > where users can suggest which package to remove. Good idea! pgpj8FtAL3D3T.pgp Description: PGP signature
