Re: [aur-general] pkgstats and unused [community] packages
On Mon, Oct 25, 2010 at 8:20 PM, Ray Rashif sc...@archlinux.org wrote:
On 26 October 2010 07:48, Christopher Brannon ch...@the-brannons.com wrote:
Allan McRae al...@archlinux.org writes:
I'd say only remove the packages that are orphans.
Here's the list of [community] orphans with less than 1% usage, according
to pkgstats:
http://paste.xinu.at/98f5
OK that's a good list, and all of those can be moved IMO.
If it hasn't been done, someone needs to check to make sure that they
are not {make,opt}depends of other non-orphaned packages.
I take back part of what I mentioned earlier. There are indeed some
packages that I believe no one uses. The best way to handle this is to
selectively remove each package that we still want to keep from the
wiki list. I've added a filter list, so remove from there (and not the
original). Wiki diffs would tell us what has been removed (and by
whom).
Set up a timeframe along with an official discussion period for this,
i.e how long we have until the filter list is final. And then the
voting, if needed.
Re: [aur-general] pkgstats and unused [community] packages
On Tue, Oct 26, 2010 at 03:46:56AM -0400, Eric Bélanger wrote:
If it hasn't been done, someone needs to check to make sure that they
are not {make,opt}depends of other non-orphaned packages.
Done. ucl is a makedepend of upx, gpsmanshp an optdep of gpsman. That's
it :)
Re: [aur-general] Orphan Request: portmidi
On 19 October 2010 04:53, SpepS sp...@gmx.com wrote: Portmidi last update was on 3 September 2009 http://aur.archlinux.org/packages.php?ID=23403 The user (denis) owns 5/16 outdated packages and the last change was on 14 May 2010. Btw, i have sent an e-mail today notifying about this to give him a chance to rescue his packages. Also, there is a duplicate (portmidi-newer) http://aur.archlinux.org/packages.php?ID=38900 that should be removed when portmidi will be updated. Thanks, SpepS. Hello, have you got any response from the portmidi maintainer? If not I can orphan his packages. Lukas
Re: [aur-general] Orphan Request: portmidi
On Tue, Oct 26, 2010 at 10:12:52AM +0200, Lukáš Jirkovský wrote: On 19 October 2010 04:53, SpepS sp...@gmx.com wrote: Portmidi last update was on 3 September 2009 http://aur.archlinux.org/packages.php?ID=23403 The user (denis) owns 5/16 outdated packages and the last change was on 14 May 2010. Btw, i have sent an e-mail today notifying about this to give him a chance to rescue his packages. Also, there is a duplicate (portmidi-newer) http://aur.archlinux.org/packages.php?ID=38900 that should be removed when portmidi will be updated. Thanks, SpepS. Hello, have you got any response from the portmidi maintainer? If not I can orphan his packages. Lukas After a week, still no risponse. Maybe it's time to orphan it.
[aur-general] Delete request
Hi, Could you please delete psearch-python3 [1] it's a dup of psearch [2], and not fixed for python3. Also can you zap pkgclean [3], its been re-uploaded with a different name [4] and the maintainer agrees it should be deleted [5] . Thanks. Simon. [1] http://aur.archlinux.org/packages.php?ID=16551 [2] http://aur.archlinux.org/packages.php?ID=7821 [3] http://aur.archlinux.org/packages.php?ID=41917 [4] http://aur.archlinux.org/packages.php?ID=41918 [5] https://bbs.archlinux.org/viewtopic.php?pid=841811#p841811
Re: [aur-general] pkgstats and unused [community] packages
On 2010-10-26 08:20 +0800 (43:2) Ray Rashif wrote: On 26 October 2010 07:48, Christopher Brannon ch...@the-brannons.com wrote: Allan McRae al...@archlinux.org writes: I'd say only remove the packages that are orphans. Here's the list of [community] orphans with less than 1% usage, according to pkgstats: http://paste.xinu.at/98f5 OK that's a good list, and all of those can be moved IMO. I take back part of what I mentioned earlier. There are indeed some packages that I believe no one uses. The best way to handle this is to selectively remove each package that we still want to keep from the wiki list. I've added a filter list, so remove from there (and not the original). Wiki diffs would tell us what has been removed (and by whom). Set up a timeframe along with an official discussion period for this, i.e how long we have until the filter list is final. And then the voting, if needed. I can see the point of removing orphans but I still think that using pkgstats as a metric is a bad idea for everything else. Casual users, i.e. those who are not actively involved on the forum or IRC won't even be aware of pkgstats. Really, who installs a distro and actively looks for a way to submit user data? And please don't try to tell me that the only users who matter are the ones who form the core community. Then you have the paranoid who won't submit anything, even if they're a small group. Ultimately pkgstats only reflect the usage of a small group of people with possibly skewed interests. (There should be a few statisticians around so it would be interesting to hear their analysis of this... let's face it, most people fail at interpret ting statistical data and ultimately do so with a bias that supports their own agenda... *cough*politicians*cough*.)* Several of those packages are niche packages too (e.g. python-sympy, vtk, avogadro), but ones that are important within their niche. If they are actively maintained then I see no reason to remove them even if they are not commonly used by the subset of users who submit stats. As it stands, I would support removal of the orphaned packages listed above but not the list based on pkgstats alone. We need a better usage metric for repo packages. Personally I think it would be better to implement a simple online vote and inform users that a package is a candidate for removal in a post_upgrade or post_install message. Users could then vote to keep the package and if it passes a threshold (e.g. 10, as required by AUR), then it does not get removed. Also, consider that a package can be moved to [community] if it gets 10 votes on the AUR. 10 votes out of thousands of users is less than 1%, maybe even less than 0.1% depending on how many AUR users there actually are. Regards, Xyne * pkgstats also uses hashed IPs to form unique IDs. Multiple users behind a single IP would only count as 1 in that case. What if that single IP represents an entire institution with hundreds of installations? p.s. Removing these packages indiscriminately will herald the apocalypse and the end of tacos as we know them.
Re: [aur-general] Delete request
On Tue, Oct 26, 2010 at 02:31:47PM +0100, Simon Stoakley wrote: Could you please delete psearch-python3 [1] it's a dup of psearch [2], and not fixed for python3. psearch-python3 contains an additional patch (actually patching is done via sed(1)) that psearch doesn't seem to provide. I think we should keep this unless the patch is superfluous. Also can you zap pkgclean [3], its been re-uploaded with a different name [4] and the maintainer agrees it should be deleted [5] . Deleted, thanks.
Re: [aur-general] pkgstats and unused [community] packages
On Tue, Oct 26, 2010 at 7:36 AM, Xyne x...@archlinux.ca wrote: I can see the point of removing orphans but I still think that using pkgstats as a metric is a bad idea for everything else. Casual users, i.e. those who are not actively involved on the forum or IRC won't even be aware of pkgstats. Really, who installs a distro and actively looks for a way to submit user data? And please don't try to tell me that the only users who matter are the ones who form the core community. Then you have the paranoid who won't submit anything, even if they're a small group. Ultimately pkgstats only reflect the usage of a small group of people with possibly skewed interests. (There should be a few statisticians around so it would be interesting to hear their analysis of this... let's face it, most people fail at interpret ting statistical data and ultimately do so with a bias that supports their own agenda... *cough*politicians*cough*.)* +57, these are all topics that were brought up during the original discussion of using pkgstats as a means to promote packages from unsupported to community, and they were never really addressed. Our system of 10 votes or 1% usage in pkgstats is completely arbitrary. We don't have any statistical means of backing up what those numbers actually mean; they were picked pretty much just because they sounded good. There was even a long-time Trusted User who resigned due to the frustration of arguing over these issues. Anyway, my take on it is that as long as the packages aren't orphans that have been out of date for a *long* time, then what's the harm in keeping them in the repo? If the packages are being maintained anyway, it benefits everyone by having them in there, and unless we're running dangerously low on resources, the cleanup process isn't that necessary. If we _are_ running dangerously low on resources, is it better to drop software that may be used by a lot of people, or would it be better to campaign to raise some money for additional resources? I'm not saying that we never need to prune things up, but at this point in time, we don't have any good means of determining what needs to go aside from the personal judgement of our TUs, which luckily, is pretty reliable. -- Aaron ElasticDog Schaefer
Re: [aur-general] pkgstats and unused [community] packages
On Tue, 26 Oct 2010 08:29:38 -0700 Aaron Bull Schaefer aa...@elasticdog.com wrote: On Tue, Oct 26, 2010 at 7:36 AM, Xyne x...@archlinux.ca wrote: I can see the point of removing orphans but I still think that using pkgstats as a metric is a bad idea for everything else. Casual users, i.e. those who are not actively involved on the forum or IRC won't even be aware of pkgstats. Really, who installs a distro and actively looks for a way to submit user data? And please don't try to tell me that the only users who matter are the ones who form the core community. Then you have the paranoid who won't submit anything, even if they're a small group. Ultimately pkgstats only reflect the usage of a small group of people with possibly skewed interests. (There should be a few statisticians around so it would be interesting to hear their analysis of this... let's face it, most people fail at interpret ting statistical data and ultimately do so with a bias that supports their own agenda... *cough*politicians*cough*.)* +57, these are all topics that were brought up during the original discussion of using pkgstats as a means to promote packages from unsupported to community, and they were never really addressed. Our system of 10 votes or 1% usage in pkgstats is completely arbitrary. We don't have any statistical means of backing up what those numbers actually mean; they were picked pretty much just because they sounded good. There was even a long-time Trusted User who resigned due to the frustration of arguing over these issues. Anyway, my take on it is that as long as the packages aren't orphans that have been out of date for a *long* time, then what's the harm in keeping them in the repo? If the packages are being maintained anyway, it benefits everyone by having them in there, and unless we're running dangerously low on resources, the cleanup process isn't that necessary. If we _are_ running dangerously low on resources, is it better to drop software that may be used by a lot of people, or would it be better to campaign to raise some money for additional resources? I'm not saying that we never need to prune things up, but at this point in time, we don't have any good means of determining what needs to go aside from the personal judgement of our TUs, which luckily, is pretty reliable. I did not have the time to actively participate in this discussion so far but Xyne's and Aaron's opinions are pretty much the same that I think. Moving orphans after some time is good, as people using those can take care of them when they're in the AUR, but that's the only good reason I see in this action. I agree on how the AUR cleanup was proposed but except for the mentioned one, I don't see any really good reason for doing this with the repository. -- Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 signature.asc Description: PGP signature
Re: [aur-general] Orphan Request: portmidi
On Tue, Oct 26, 2010 at 01:55:02PM +0200, SpepS wrote: After a week, still no risponse. Maybe it's time to orphan it. I'll move portmidi to [community] today or tomorrow anyway, so there's actually not much need to orphan it. Anyways, I quickly uploaded a fixed source package heavily based on SpepS's PKGBUILD.
Re: [aur-general] pkgstats and unused [community] packages
Am Dienstag 26 Oktober 2010, 16:55:27 schrieb PyroPeter: On 10/26/2010 05:40 AM, Kaiting Chen wrote: Unrelated but thinking ahead, would it be possible to go ahead and get rid of /etc/pacman.d/mirrorlist and pull from a main http://www.archlinux.org/repository? Then have that repository instead be a proxy to the actual mirrors that round robin's them, possibly with some kind of IP geolocated weighting? Then the package downloads can be easily tracked through this main proxy. To actually track the tcp-traffic (indirectly containing the name of the requested package) archlinux.org would have to _proxy_ the traffic (_all_ data would go _twice_ through their network infrastructure). This would make the concept of mirrors useless. The other possibility would be a round-robin domain name (like e.g. irc.freenode.net). This way archlinux.org could only log that a connection was made, but not which packages were requested. (Additionally all mirrors would have to use the same folder hierarchy) TL,DR: There is no technical way to monitor all package downloads. Regards, PyroPeter Why not let pacman do the job (similar to how yaourt uses aurvote)? Let pacman send a ping to some server like aurvote does. Michael -- PGP-Key: 51C1D000 Jabber: aku...@furdev.org http://akurei.de signature.asc Description: This is a digitally signed message part.
Re: [aur-general] pkgstats and unused [community] packages
Am 26.10.2010 20:05, schrieb Michael Düll: Why not let pacman do the job (similar to how yaourt uses aurvote)? Let pacman send a ping to some server like aurvote does. Michael Because pacman is a distro agnostic tool. Other distros do not have something like the AUR.
[aur-general] deletion request: nickle
Please delete the package 'nickle'. It was pushed to extra less than 24 hours after I posted my package. In related news, beware of JGC: he's magical. d
Re: [aur-general] deletion request: nickle
On 10/26/2010 09:51 PM, Dave Reisner wrote: Please delete the package 'nickle'. It was pushed to extra less than 24 hours after I posted my package. In related news, beware of JGC: he's magical. d Done thanks
[aur-general] Cleaning up aqpm / shaman packages
I'd like to remove a few old and broken aqpm / shaman packages. AFAIK, the only working packages in the AUR are aqpm-git[1] and shaman-svn[2] Candidates for removal (depend on an old version of libalpm and don't build anymore): shaman [3] shaman1-git [4] aqpm [5] libaqpm-git [6] Additionally, the following pkgs depend on shaman, I'm not sure what to do with these: shaman-plasma [7] shaman-plasma-svn [8] Any thoughts / objections? [1] http://aur.archlinux.org/packages.php?ID=40830 [2] http://aur.archlinux.org/packages.php?ID=40831 [3] http://aur.archlinux.org/packages.php?ID=15422 [4] http://aur.archlinux.org/packages.php?ID=29028 [5] http://aur.archlinux.org/packages.php?ID=29600 [6] http://aur.archlinux.org/packages.php?ID=25472 [7] http://aur.archlinux.org/packages.php?ID=19166 [8] http://aur.archlinux.org/packages.php?ID=19165
[aur-general] aur website default ssl
Hi, we are now using default https for aur.archlinux.org. Some aur helpers may need adjustment, others like cower/slurpy already works as expected. Kudos for their maintainers for following the aur development -- Ionuț
Re: [aur-general] pkgstats and unused [community] packages
Not true, Arch could set up a round robin proxy to other mirrors such that when a package is requested it returns a HTTP 302 or HTTP 303 redirect. Then the only network traffic routed through Arch servers would only be the request HTTP headers which is quite insubstantial but would still allow real package statistics to be retrieved. Kaiting. On Tue, Oct 26, 2010 at 10:55 AM, PyroPeter abi1...@googlemail.com wrote: On 10/26/2010 05:40 AM, Kaiting Chen wrote: Unrelated but thinking ahead, would it be possible to go ahead and get rid of /etc/pacman.d/mirrorlist and pull from a main http://www.archlinux.org/repository? Then have that repository instead be a proxy to the actual mirrors that round robin's them, possibly with some kind of IP geolocated weighting? Then the package downloads can be easily tracked through this main proxy. To actually track the tcp-traffic (indirectly containing the name of the requested package) archlinux.org would have to _proxy_ the traffic (_all_ data would go _twice_ through their network infrastructure). This would make the concept of mirrors useless. The other possibility would be a round-robin domain name (like e.g. irc.freenode.net). This way archlinux.org could only log that a connection was made, but not which packages were requested. (Additionally all mirrors would have to use the same folder hierarchy) TL,DR: There is no technical way to monitor all package downloads. Regards, PyroPeter -- freenode/pyropeter 12:50 - Ich drücke Return. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] aur website default ssl
On Tue 26 Oct 2010 23:50 +0300, Ionuț Bîru wrote: we are now using default https for aur.archlinux.org. Some aur helpers may need adjustment, others like cower/slurpy already works as expected. Kudos for their maintainers for following the aur development Hmm. How did you go about doing this? Can you make it possible to visit the site via normal http as well? Thanks.
[aur-general] [google-talkplugin] How to build an older version of openssl
Hello, guys. Google Talk Plugin for GMail is not working anymore for me (and others...) because it relies on libssl.so.0.9.8. But for my surprise, the binary GoogletalkPlugin is a 32 bits executable, even for the 64 bits package. It comes right after the original deb package, provided by Google. To make things short, I tried to downgrade the lib32-openssl PKGBUILD to version 0,9,8n. It compiles fine, but the resulting libraries (libcrypto.so.0.9.8 and libssl.so.0.9,8) are ELF64, when they should be ELF32. You can view the PKGBUILD in http://pastebin.com/04xsippr So, should I need a 32 bits chroot for that? Shouldn't the multilib compiler be enough? -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto Linux user #524555 ---
Re: [aur-general] pkgstats and unused [community] packages
On Tue 26 Oct 2010 16:36 +0200, Xyne wrote: On 2010-10-26 08:20 +0800 (43:2) Ray Rashif wrote: I take back part of what I mentioned earlier. There are indeed some packages that I believe no one uses. The best way to handle this is to selectively remove each package that we still want to keep from the wiki list. I've added a filter list, so remove from there (and not the original). Wiki diffs would tell us what has been removed (and by whom). Set up a timeframe along with an official discussion period for this, i.e how long we have until the filter list is final. And then the voting, if needed. I can see the point of removing orphans but I still think that using pkgstats as a metric is a bad idea for everything else. Casual users, i.e. those who are not actively involved on the forum or IRC won't even be aware of pkgstats. Really, who installs a distro and actively looks for a way to submit user data? And please don't try to tell me that the only users who matter are the ones who form the core community. I wouldn't say that. I would say that the only users who matter are the ones that participate. For example you can't justly complain about the results of an election if you haven't educated yourself about it and voted. I believe that before any action is taken to move packages back to unsupported there should be a public notice, and users should be able to give feedback. Several of those packages are niche packages too (e.g. python-sympy, vtk, avogadro), but ones that are important within their niche. If they are actively maintained then I see no reason to remove them even if they are not commonly used by the subset of users who submit stats. As it stands, I would support removal of the orphaned packages listed above but not the list based on pkgstats alone. We need a better usage metric for repo packages. Let's be clear here. This isn't about removal of packages. It's about moving packages from one repo to another. Community to aur/unsupported. Personally I think it would be better to implement a simple online vote and inform users that a package is a candidate for removal in a post_upgrade or post_install message. Users could then vote to keep the package and if it passes a threshold (e.g. 10, as required by AUR), then it does not get removed. Hmm, now that's an interesting idea. I like the idea of people giving feedback, and voting. I'm not too keen on putting it in a package's install scripts though.
Re: [aur-general] aur website default ssl
On Tue, Oct 26, 2010 at 1:50 PM, Ionuț Bîru ib...@archlinux.org wrote: Hi, we are now using default https for aur.archlinux.org. Some aur helpers may need adjustment, others like cower/slurpy already works as expected. Kudos for their maintainers for following the aur development Hi I maintain clyde lately. I try to keep it working anyways. This mandatory switch to https breaks clyde's AUR support. Clyde's AUR support is the only reason to use it, really... it is an AUR helper after all. Forcing all traffic to https is not what I would call default. Default would be cool but generally a default option is not the _only_ option. I hadn't joined aur-dev. I am assuming the switch was announced there. I already am a part of this mailing list and most of what I receive from it is junk to me. I also joined the pacdev mailing list long ago but filtered that because it fills my mailbox with stuff I don't care about. All I care about are API changes to libalpm, really, and I usually just diff the sources to find them. Out of curiosity I looked at slurpy on github and it hasn't been updated since July. Cower was updated 4 days ago. If an AUR helper uses a sufficiently high-level interface they won't need to update because they get forwarded to the HTTPS URI. Everything is automagically fixed for them. Clyde is probably the only AUR helper to suffer from this because of its low-level Luasocket library. Maybe paktahn as well. Kudos to falconindy at least for updating cower to use https by default. I'm glad that logins to the AUR are now encrypted. Previously they weren't which is always surprising to find out. Other than logins I could care less if my traffic is sniffed. I know the logic is easier to just switch _everything_ to HTTPS but could maybe we just use https for logins? Could you allow HTTPS to be optional (except for logins) and then give validity to the term default? -- -Justin
[aur-general] deletion request
please delete this packages * * *qgtkstyle-svn* *reason: qgtk now is part of kde, and this svn don't be moved anymore* http://aur.archlinux.org/packages.php?ID=16964 yapos this proyect is down, the script is obsolete http://aur.archlinux.org/packages.php?ID=39367 kdropbox kdropbox was now called kfilebox, and kfilebox was uploaded in the aur already and works fine http://aur.archlinux.org/packages.php?ID=36752 tanks folks
[aur-general] TU Application
Hi aur-general, my name is Kaiting Chen and Xyne has decided to sponsor me for my TU application. I'm twenty one years old and a senior at Duke University studying Biomedical Engineering with a minor in Economics. I have also been a web developer and systems administrator for about four years now and am currently working on a rather long and protracted project for the university. I have been using Linux on a daily basis for about seven years now starting with Red Hat Linux, then Debian, Gentoo and finally Arch Linux for the last three years. And I use C, C++, x86 ASM, Java, Python, Ruby, PHP, and Javascript on a daily basis. I have Arch installed on four servers in total as well as on one virtual machine. I'm not ashamed to admit that I run a Windows 7 notebook as my only physical computer; though it's only role these days is to not bother me while I SSH into my Linux machines. I maintain a small cluster running Arch where I hand out free shell accounts to anyone who wants them. Currently this cluster has one hundred and twenty five users though I am in the process of updating its infrastructure to (hopefully) scale up to a couple thousand. The most important services on this cluster are/were glusterfs, nfs, ntpd, httpd, vsftpd, postfix, dovecot, postgresql, ejabberd, slapd, openvpn, memcached, pvpgn (this list is being updated quite often). I currently maintain thirty packages in the AUR, most of which I do not use but would be unhappy in seeing them orphaned. I would like to become a Trusted User simply because I would like to maintain packages more effectively. Recently there's been a thread on aur-general about the possible removal of hundreds of packages from [community] which makes me very worried. Packages such as cacti, courier-*, ejabberd, freeradius*, ipsec-tools, monit, roundcubemail, scilab, and *ircd are very important to people who run Arch on the server such as myself. This list evinces a fundamental problem however that there is simply not enough manpower to maintain the current repositories. Because I am able (or hopefully will be deemed so by the powers that be/grant TU priveleges) I would like to help alleviate this condition. Arch allows me to focus on the work that I do; it should be obvious that helping to ensure that Arch functions smoothly and efficiently is a necessary task for anyone who has made this distribution a valuable part of their workflow. In more concrete terms of how I want to contribute, I would like to start by adopting python-openbabel, freeimage, metakit, gen2shp, tdl, python-bsddb, and other orphaned packages in [community] once I have the chance to take a closer look at the orphan list. I'd also like to pull smalltalk, burp, bti, liboauth, and vim-align into [community]. I would also like to work on bringing some of the packages in [community] up to date such as rsyslog, pyinotify, openntpd, and ngspice. I would also like to work on maintain the Arch web presence. I think that a separate login is needed for each part of the site is something that should be fixed. The AUR is also somewhat outdated and I in large part agree with the page here: http://wiki.archlinux.org/index.php/AUR_2. That's about all I can think of for now. Please feel free to ask any questions and thanks for taking the time to consider my application. Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] deletion request
On Wed, Oct 27, 2010 at 12:26:50AM -0300, Gonzalo Seguel wrote: *qgtkstyle-svn* *reason: qgtk now is part of kde, and this svn don't be moved anymore* http://aur.archlinux.org/packages.php?ID=16964 Deleted. yapos this proyect is down, the script is obsolete http://aur.archlinux.org/packages.php?ID=39367 How come? The package still builds fine, sources are available (actually, they are included in the source tarball) and this package has been updated less than two months ago... kdropbox kdropbox was now called kfilebox, and kfilebox was uploaded in the aur already and works fine http://aur.archlinux.org/packages.php?ID=36752 Deleted.
