Re: [aur-general] AUR 3.3.0 released
There are three very recent instances I'd like to use in examples here where the situation didn't seem right regarding the Request/Flag out of date features: 1. mdocml[1] - The maintainer is a nice friendly guy, I've emailed him back and forth to help him with the recent issues... but he doesn't appear to subscribe to the comments, or have the free time to maintain the package fully. (i'm referencing the recent comments on it) P.S. it still isn't right, and yes, I have even provided him with a fixed PKGBUILD [2]... but as mentionned, he is busy elsewhere, and wrote in a comment don't flag out of date if there is no new upstream version 2. musl[3] - The maintainer is not willing/able to support clang users (all it really needs is a simple if/else adding for cflags). I submitted an orphan request, it was accepted[4] - but before I got home from work, he re-adopted the package and still hasn't fixed it! 3. pnmixer[5] - I'm now an active developer in this project and we've just finished updating it to gtk3 and fixed some major bugs. The package was already flagged out of date, so I submitted an orphan request, and it was rejected[6] stating email the maintainer - which seemed to be the opposite of what I was told by Lukas[7] Sorry that's a little bit link-heavy! Also thanks to the people that are working hard on improving the AUR - I've had many requests accepted in less than a couple of hours which is great, the above 3 I'm just highlighting as the bad occasions as they might help someone come up with an idea for how the process could become more refined. Thanks, Steven. [1] https://aur.archlinux.org/packages/mdocml/ [2] https://gist.github.com/stevenhoneyman/e1abfd3a434974b125bd [3] https://aur.archlinux.org/packages/musl [4] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000313.html [5] https://aur.archlinux.org/packages/pnmixer/ [6] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000307.html [7] https://mailman.archlinux.org/pipermail/aur-general/2014-July/029048.html On 9 July 2014 15:34, Nowaker enwuk...@gmail.com wrote: Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed. Totally disagree. I always go to My Packages page to see if there's anything to take care of. That's because packages flagged out-of-date are red, which is awesome. Doing `for p in packages; do read latest comment done` manually doesn't sound like a good idea to me. I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional. The maintainer has to care about the discussion about their package. Disable notifications should point to Disown package. trollface/ -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
Re: [aur-general] AUR 3.3.0 released
1. The man pages are installed in /usr/share/man1 instead of /usr/share/man/man1 (etc) in the current PKGBUILD. Don't guess based on something you haven't tried or tested. 2. I couldn't care less about clang right now. I've never used it. I aim to support as many configurations as possible though. If it was a dick move then it should have been rejected. On 9 July 2014 18:18, Dave Reisner d...@falconindy.com wrote: On Wed, Jul 09, 2014 at 05:58:02PM +0100, Steven Honeyman wrote: There are three very recent instances I'd like to use in examples here where the situation didn't seem right regarding the Request/Flag out of date features: 1. mdocml[1] - The maintainer is a nice friendly guy, I've emailed him back and forth to help him with the recent issues... but he doesn't appear to subscribe to the comments, or have the free time to maintain the package fully. (i'm referencing the recent comments on it) P.S. it still isn't right, and yes, I have even provided him with a fixed PKGBUILD [2]... but as mentionned, he is busy elsewhere, and wrote in a comment don't flag out of date if there is no new upstream version Well, he's right. I see nothing resembling a pending issue here, so clearly the current workflow was successful. This is orthogonal to the idea that it could be improved. 2. musl[3] - The maintainer is not willing/able to support clang users (all it really needs is a simple if/else adding for cflags). I submitted an orphan request, it was accepted[4] - but before I got home from work, he re-adopted the package and still hasn't fixed it! Wow, really? That's a seriously dick move on your part. The maintainer has chosen to make the package work with the Arch defaults. That you want to add extra complexity to support non-standard setups is something that he's entirely in the right to ignore. *You* should be the one accepting the extra burden. 3. pnmixer[5] - I'm now an active developer in this project and we've just finished updating it to gtk3 and fixed some major bugs. The package was already flagged out of date, so I submitted an orphan request, and it was rejected[6] stating email the maintainer - which seemed to be the opposite of what I was told by Lukas[7] Seems like a matter of broken human processes. The maintainer seems idle, with their last login being ~6 months ago. Sorry that's a little bit link-heavy! Also thanks to the people that are working hard on improving the AUR - I've had many requests accepted in less than a couple of hours which is great, the above 3 I'm just highlighting as the bad occasions as they might help someone come up with an idea for how the process could become more refined. Just remember that it's a two way street... Thanks, Steven. [1] https://aur.archlinux.org/packages/mdocml/ [2] https://gist.github.com/stevenhoneyman/e1abfd3a434974b125bd [3] https://aur.archlinux.org/packages/musl [4] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000313.html [5] https://aur.archlinux.org/packages/pnmixer/ [6] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000307.html [7] https://mailman.archlinux.org/pipermail/aur-general/2014-July/029048.html On 9 July 2014 15:34, Nowaker enwuk...@gmail.com wrote: Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed. Totally disagree. I always go to My Packages page to see if there's anything to take care of. That's because packages flagged out-of-date are red, which is awesome. Doing `for p in packages; do read latest comment done` manually doesn't sound like a good idea to me. I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional. The maintainer has to care about the discussion about their package. Disable notifications should point to Disown package. trollface/ -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
Re: [aur-general] AUR 3.3.0 released
On 9 July 2014 18:39, Dave Reisner d...@falconindy.com wrote: I'm going by the comments. If there's (still) a problem, you haven't brought it up in the past 4 days since the maintainer updated the package. Orphaning the package in this case isn't reasonable. I have, just through e-mail directly to the maintainer. I didn't request it was to be orphaned; someone flagged it as out of date because there was no other option to click such as needs fixing (which is how this discussion started...) You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here My AUR packages don't support/aren't tested with clang... but if someone commented on one requesting and explaining a simple change so that more people are able to use it, then I would implement it.
Re: [aur-general] AUR 3.3.0 released
On 9 July 2014 20:37, Bartłomiej Piotrowski b...@bpiotrowski.pl wrote: Yes, I have accepted the request, then realized it's completely untrue and asked the maintainer to re-adopt it. Additionally I'm the one who flagged the package because, obviously, there is a newer release, not because it's broken. Do you really see the point in fixing compilation using clang when literally nothing in PKGBUILD references it? I do not. Please stop wasting time, either people's and yours. -- Bartłomiej Piotrowski http://bpiotrowski.pl/ That makes less sense than falconandy's responses. Firstly, musl 1.0.3 was released June 6th [1]. The AUR package was updated to this version on June 7th [2] - there is not a newer release, and 1.0.3 is still the current stable version. So if you did flag as out of date, it's *you* wasting his time. As for your second point, that's as stupid as saying literally nothing in the linux kernel references brand new laptop so there's no point in fixing drivers for it [1] http://git.musl-libc.org/cgit/musl/commit/?h=rs-1.0id=30bd499ae1f62e9d2fad4282d42057083709e0eb [2] http://pkgbuild.com/git/aur-mirror.git/commit/musl/PKGBUILD?id=5588dabbf0bc68b3fad59e4030a28f736ac4d8ca
Re: [aur-general] AUR 3.3.0 released
On 9 July 2014 21:28, Bartłomiej Piotrowski b...@bpiotrowski.pl wrote: If only you were curious enough to actually use musl at least once it would be clear to you that the branch naming scheme used by upstream is at least misleading. Whatever you do 1.1.x is newer than 1.0 and in many cases is more useful. But sure, better whine about clang and make unrelated comparison to developemnt of drivers in Linux kernel. Good luck, you are going to need it a lot. -- Bartłomiej Piotrowski http://bpiotrowski.pl/ treat others as you would be treated; respect them and their views, even if you disagree with them. - Arch Wiki Are you really that ignorant/stupid/insulting? Here let me help you: (from http://www.musl-libc.org/download.html) --- Current Versions Mainline - 1.1.3 Stable - 1.0.3 --- Oh! did I forget to mention that it helps if you use bother to use the search facility once in a while. Click this: https://aur.archlinux.org/packages/musl-latest/ ...and check the submitter/maintainer/packager Steven. (aka stevenhoneyman if you STILL haven't realised!)
Re: [aur-general] AUR 3.3.0 released
The trouble is there are too many people that don't (or can't) think about *why* something might not be working. It's often the users' fault :) Suppose someone sets ld.gold as their default linker because the internet told them it was better... and then tries to compile imagemagick... Steven. On 8 July 2014 12:30, Attila Bukor r1pp3rj...@w4it.eu wrote: There are two types of comments imho: a) discussion about how the package should be improved, etc; b) the package doesn't build in some cases, which *needs* attention from the maintainer. Even in case the maintainer is subscribed to notifications, they can miss these b) kinds of comments if there are lots of discussion no the package. For this there should be a flag not working next to the flag out of date button. Just my two cents. r1pp3rj4ck On 07/05/2014 09:59 PM, Steven Honeyman wrote: Wouldn't this push more work towards the AUR maintainers though? What actually happens when someone requests a package is to be orphaned? Can the package maintainer un-request it by doing something? I guess I just assumed (like the ML previously) that a bunch of people would get an email with the request in it - which nobody really wants to see! Definitely agree on the comment+checkbox idea being a bad one. As you said, everyone's problem would demand attention. Steven. On 5 July 2014 19:39, A Rojas nqn1976l...@gmail.com wrote: Carl Schaefer wrote: How about adding a needs attention checkbox when submitting a comment that, when checked, would email the maintainer and raise an attention requested flag on the package display page? The maintainer could check an AR reset checkbox when submitting his/her own comment, which would clear the flag. Carl This is calling for abuse. Almost everybody will consider their problem to be worth of attention. Maintainers should be subscribed to be notified of comments in their packages. If they're not, then they're not doing their job properly and requesting orphaning is justified IMO.
Re: [aur-general] AUR 3.3.0 released
Does anyone else think there is now just one thing missing from the request feature (or a different link)? I keep thinking this package is broken or this package needs attention (for reasons other than being out of date or abandoned), and there isn't a suitable button! Yes, the maintainer *should* be watching the comments, but that's very often not the case. Currently, I think my only choices are: 1. Flag as to be orphaned (even though I know the maintainer is still active) 2. Flag as out of date (even though it isn't) Examples might include: VCS packages that no longer build properly; or PKGBUILDs that do something unintentional (copy a file to the wrong directory, etc); or packages that don't build anymore because of a changed dependency. Just wondered if those would be considered reasons for flagging as out of date, or if anyone agrees this would be useful to have? Thanks, Steven. On 5 July 2014 14:23, Lukas Fleischer archli...@cryptocrack.de wrote: Hello, I am pleased to announce that AUR 3.3.0 has just been released. The official AUR setup [1] has already been updated. This release includes several improvements to the package request feature and a couple of bug fixes. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.3.0 [3] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] AUR 3.3.0 released
Wouldn't this push more work towards the AUR maintainers though? What actually happens when someone requests a package is to be orphaned? Can the package maintainer un-request it by doing something? I guess I just assumed (like the ML previously) that a bunch of people would get an email with the request in it - which nobody really wants to see! Definitely agree on the comment+checkbox idea being a bad one. As you said, everyone's problem would demand attention. Steven. On 5 July 2014 19:39, A Rojas nqn1976l...@gmail.com wrote: Carl Schaefer wrote: How about adding a needs attention checkbox when submitting a comment that, when checked, would email the maintainer and raise an attention requested flag on the package display page? The maintainer could check an AR reset checkbox when submitting his/her own comment, which would clear the flag. Carl This is calling for abuse. Almost everybody will consider their problem to be worth of attention. Maintainers should be subscribed to be notified of comments in their packages. If they're not, then they're not doing their job properly and requesting orphaning is justified IMO.
Re: [aur-general] AUR 3.2.0 released
Nice! Does the 14 day rule still apply for orphan requests? Thanks, Steven. On 1 July 2014 20:58, Lukas Fleischer archli...@cryptocrack.de wrote: Hello, I am pleased to announce that AUR 3.2.0 has just been released. The official AUR setup [1] has already been updated. You can now send deletion, merge and orphan requests by using the File Request link in the package actions box. Please use the web interface instead of manually sending mails to aur-general or aur-requests from now on. Note to all AUR helper maintainers: There also is a new version of the RPC interface (v3) that makes the result values types a bit more consistent. See FS#40963 [2] for details. For a comprehensive list of changes, please consult the Git log [3]. As usual, bugs should be reported to the AUR bug tracker [4]. [1] https://aur.archlinux.org/ [2] https://bugs.archlinux.org/task/40963 [3] https://projects.archlinux.org/aur.git/log/?id=v3.2.0 [4] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] package blacklist?
I think the first line of your PKGBUILD might be the clue! pkgbase=xorg-server I could be wrong though, just guessing. Steven. On 30 June 2014 17:30, Mike Hobbs mho...@fluid.com wrote: I maintain the xorg-server-bug54168 package in AUR, which is a replacement for xorg-server that contains a small bug fix that upstream is not addressing. Anyway, when I submit a new version for the xorg-server 1.15.2 update, it tells me that xorg-server is on the package blacklist, please check if it's available in the official repos. I've not seen this error before when updating my package. Is there any documentation about what this blacklist is, or how to avoid it, or how to petition for an override? I've done the standard searches, but have only come across random forum and mail list posts; nothing comprehensive. Thanks, - Mike
Re: [aur-general] Information request about libnss-mysql
Googled it out of curiosity... google has a cache of that page (in French!). Hope it's useful somehow: Détails du paquet: libnss-mysql 1.5-2 Description: Store your UNIX user accounts in MySQL Lien: http://libnss-mysql.sourceforge.net/ Catégorie: lib Licence: GPL Contributeur: Aucun Mainteneur: Aucun Votes: 5 Première soumission: 2007-11-04 01:55 Dernière mise à jour: 2012-05-15 10:43 Dépendances (1) mysql=5.0.15 Sources http://sourceforge.net/projects/libnss-mysql/files/libnss-mysql/1.5/libnss-mysql-1.5.tar.gz On 29 June 2014 17:44, Jeremy Audet ichimonj...@gmail.com wrote: Old accounts (older than either 500 days or two years, not sure which) were recently purged. [1] libnss-mysql was last updated in May 2012, which would probably explain why the submitter, maintainer and packager is listed as None. I'll leave it up to the TUs to confirm this hypothesis and let you know whether there's still any way to get that account info. — Jeremy Ichimonji10 Audet [1a] https://mailman.archlinux.org/pipermail/aur-general/2014-January/027030.html [1b] https://mailman.archlinux.org/pipermail/aur-general/2014-February/027039.html
[aur-general] Redundant package for deletion
Tintwizard is provided by the Arch package 'tint2' [1], so this separate package [2] is now redundant and can be removed. Thanks, Steven. [1] https://www.archlinux.org/packages/?name=tint2 [2] https://aur.archlinux.org/packages/tintwizard/
Re: [aur-general] changing PKGNAME of md5deep to hashdeep
OK, I'm not a TU (yet?)... but as the person that contacted you probably did so because of a post to this ML of mine from 5 days ago, I think I should link this [1] here. A few people replied, and md5deep was decided as the real name for the package. I have strong feelings that it should remain as-is, given that anybody searching for it will look for the name md5deep because that's what it is named everywhere else (i.e. all linux distros). Steven. [1] https://mailman.archlinux.org/pipermail/aur-general/2014-May/028617.html On 6 June 2014 15:29, David Kaylor dpkay...@gmail.com wrote: A user is requesting that the md5deep package name be changed to hashdeep, which I agree seems consistent with the project maintainer's wishes, since all development of md5deep has been moved to github under the hashdeep name. Do any Trusted Users have strong feelings about this or advice for me? And if I go ahead with the name change, what is the best procedure? I'm assuming I would need to do a replaces=(md5deep) and/or a provides=(md5deep) and then request that comments, etc. be moved over.
Re: [aur-general] Orphan request: l3afpad
Still no email reply from the current maintainer after 2 weeks, and he hasn't updated or commented on it at all - so would it be possible to orphan [1] so that I can update it please? Thanks, Steven. [1] https://aur.archlinux.org/packages/l3afpad On 3 June 2014 17:46, Steven Honeyman stevenhoney...@gmail.com wrote: It was 11 days ago I sent the email. Would you like me to reply again to this in 3 more days if he has not responded? Thank-you, Steven. On 3 June 2014 11:38, Maxime Gauduin aluc...@gmail.com wrote: On Sat, May 31, 2014 at 4:50 PM, Steven Honeyman stevenhoney...@gmail.com wrote: The AUR package l3afpad is in need of an update as the source file has changed URL and it will soon stop working when the author takes his old page down. I'm willing to take over as maintainer for this package if possible. I already emailed the current maintainer, but he hasn't replied. https://aur.archlinux.org/packages/l3afpad Thanks, Steven When did you email him? He last logged in last month so you will need to wait 2 weeks before I can disown the package. -- Maxime
Re: [aur-general] Orphan request: l3afpad
It was 11 days ago I sent the email. Would you like me to reply again to this in 3 more days if he has not responded? Thank-you, Steven. On 3 June 2014 11:38, Maxime Gauduin aluc...@gmail.com wrote: On Sat, May 31, 2014 at 4:50 PM, Steven Honeyman stevenhoney...@gmail.com wrote: The AUR package l3afpad is in need of an update as the source file has changed URL and it will soon stop working when the author takes his old page down. I'm willing to take over as maintainer for this package if possible. I already emailed the current maintainer, but he hasn't replied. https://aur.archlinux.org/packages/l3afpad Thanks, Steven When did you email him? He last logged in last month so you will need to wait 2 weeks before I can disown the package. -- Maxime
Re: [aur-general] AUR 3.0.0 released
You'll need qt4 and qt5 installed to build the package though. So that means a large download of qt5, unnecessary writes to the users SSD, increased install time, and then having to remove qt5 again afterwards! (or the opposite way around qt5-qt4) On 1 June 2014 15:51, Doug Newgard scim...@archlinux.info wrote: On 2014-06-01 09:50, Johannes Löthberg wrote: On 01/06, Doug Newgard wrote: Please don't. You'll force the user to have both qt4 and qt5 installed even if they just want one of them. No?.. Both will be built by default, but building and installing packages are two very separate things ... In a binary repo, that is true, but not in the AUR.
[aur-general] Package removal request: ureadahead
I've been looking for a preload solution, and found this outdated/orphaned wiki article [1] which says the kernel module is no longer available (replaced by systemd), but the userspace package ureadahead is still in the AUR [2] (orphaned, out of date, and no comments for 2 years!) Thanks, Steven [1] https://wiki.archlinux.org/index.php/Ureadahead [2] https://aur.archlinux.org/packages.php?ID=37889
Re: [aur-general] Another removal request
You're as keen as I am :) What would be useful is a Flag for deletion button on the AUR. It could (for example) only show up once a package has been flagged as out of date for a month, and require a short reason why. It'd save all these poor devs getting cluttered mailing lists, and would definitely clean up the number of useless/obsolete/broken packages as more people would be reporting them. - Steven On 1 June 2014 21:44, Charles Bos charlesb...@gmail.com wrote: Hello, Can the following package be removed please: https://aur.archlinux.org/packages/icewm-testing/ It's basically just an out of date duplicate of the icewm package in the official repos. It uses exactly the same sourceforge.net sources as the official package, the only difference being that it's a version out of date. It's also orphaned, hasn't been updated since 2011 and has just 6 votes. Regards
[aur-general] Another two for deletion!
These AUR packages are duplicates of packages alreadu in the main repositories: Busybox: https://aur.archlinux.org/packages/busybox-static/ https://www.archlinux.org/packages/community/x86_64/busybox/ Wine Gecko: https://aur.archlinux.org/packages/wine-stable_gecko/ https://www.archlinux.org/packages/multilib/x86_64/wine_gecko/ Thanks, Steven
[aur-general] Orphan request: l3afpad
The AUR package l3afpad is in need of an update as the source file has changed URL and it will soon stop working when the author takes his old page down. I'm willing to take over as maintainer for this package if possible. I already emailed the current maintainer, but he hasn't replied. https://aur.archlinux.org/packages/l3afpad Thanks, Steven
[aur-general] Duplicated package removal request
I've just noticed that the md5deep [1] package (kept up-to-date, first submitted in 2006) someone has duplicated to hashdeep [2] in 2014. They compile from exactly the same source, and produce the same binaries. Can the hashdeep package be removed? Also, would anybody be interested in moving md5deep over to the community repo? It's a very popular set of checksum tools that have many more features than md5sum,sha1sum (etc). Thanks, Steven. [1] https://aur.archlinux.org/packages/md5deep/ [2] https://aur.archlinux.org/packages/hashdeep/
Re: [aur-general] Duplicated package removal request
That's not the name of the software though. From the first line of the official readme file: This is md5deep, a set of cross-platform tools to computer hashes, or message digests, for any number of files while optionally recursively digging through the directory structure. On 1 June 2014 00:59, Timofey Titovets nefelim...@gmail.com wrote: I general user, but i think what hashdeep is more right name for 'Universal' tool set. 2014-06-01 2:33 GMT+03:00 Steven Honeyman stevenhoney...@gmail.com: I've just noticed that the md5deep [1] package (kept up-to-date, first submitted in 2006) someone has duplicated to hashdeep [2] in 2014. They compile from exactly the same source, and produce the same binaries. Can the hashdeep package be removed? Also, would anybody be interested in moving md5deep over to the community repo? It's a very popular set of checksum tools that have many more features than md5sum,sha1sum (etc). Thanks, Steven. [1] https://aur.archlinux.org/packages/md5deep/ [2] https://aur.archlinux.org/packages/hashdeep/ -- Best regards, Timofey.
Re: [aur-general] Duplicated package removal request
Just to add to that, it's named md5deep in every other linux distro, for example: http://http.us.debian.org/debian/pool/main/m/md5deep/ http://pkgs.fedoraproject.org/repo/pkgs/md5deep/ http://software.opensuse.org/download.html?project=utilitiespackage=md5deep On 1 June 2014 01:10, Steven Honeyman stevenhoney...@gmail.com wrote: That's not the name of the software though. From the first line of the official readme file: This is md5deep, a set of cross-platform tools to computer hashes, or message digests, for any number of files while optionally recursively digging through the directory structure. On 1 June 2014 00:59, Timofey Titovets nefelim...@gmail.com wrote: I general user, but i think what hashdeep is more right name for 'Universal' tool set. 2014-06-01 2:33 GMT+03:00 Steven Honeyman stevenhoney...@gmail.com: I've just noticed that the md5deep [1] package (kept up-to-date, first submitted in 2006) someone has duplicated to hashdeep [2] in 2014. They compile from exactly the same source, and produce the same binaries. Can the hashdeep package be removed? Also, would anybody be interested in moving md5deep over to the community repo? It's a very popular set of checksum tools that have many more features than md5sum,sha1sum (etc). Thanks, Steven. [1] https://aur.archlinux.org/packages/md5deep/ [2] https://aur.archlinux.org/packages/hashdeep/ -- Best regards, Timofey.
[aur-general] What stops more packages moving from AUR to Community?
Reading the wiki, I got the impression that AUR packages with more than 10 votes would be considered worthy enough to move to the Community repo. I understand that the ones with thousands of votes haven't moved due to licence type issues or binary requirements (e.g. spotify, minecraft, teamviewer, acrobat reader)... but something as simple as Archey https://aur.archlinux.org/packages/archey/ currently has 415 votes, and is used my many people for inclusions on screenshots etc (I found it by searching for it, after seeing it on the forums!) - that kind of thing I would have expected would be a no-brainer to be moved across into Community. I count roughly 9100 packages in the AUR with more than 10 votes! Is it a lack of TUs having time to maintain more than they currently do that's holding back many of them? (that's not meant as a criticism of the TUs; being understaffed is a valid explanation) Either way, perhaps the Wiki should be changed to say 1000 votes instead :D
[aur-general] Orphan deletion requests - (nano-all-svn) and (nano-svn)
Please can these two out-of-date, not-updated, orphaned AUR packages be deleted? https://aur.archlinux.org/packages/nano-svn/ https://aur.archlinux.org/packages/nano-all-svn/ I have just uploaded a replacement up-to-date package that replaces the need for those two: https://aur.archlinux.org/packages/nano-latest/
Re: [aur-general] Orphan deletion requests - (nano-all-svn) and (nano-svn)
I'd considered that, but it's still been stable (i.e. not superseded) for over a year now, and there are 2.3.3 release candidates referred to as devel/unstable On 26 May 2014 15:34, Nowaker enwuk...@gmail.com wrote: I have just uploaded a replacement up-to-date package that replaces the need for those two: https://aur.archlinux.org/packages/nano-latest/ The project refers to nano 2.3.x branch as devel, so nano-devel or nano-unstable would be the right package name I believe. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
Re: [aur-general] removal request
Not only that - it's yet another pointless package! All it does is unzip 1 file... That's worse than firefox addon packages or desktop wallpapers. On 26 May 2014 20:29, Alexej Magura sickhadas@gmail.com wrote: This is more of should this be removed; if so, please remove it-request. package-name: epsxe-bios-scph1001 package-url: https://aur.archlinux.org/packages/epsxe-bios-scph1001/ I know that the package *even* states that it is illegal to use said package without owning an actual playstation console, but still... isn't this kinda like telling people that it's illegal to steal your car, but then leaving the keys on the hood and going about your business? Peeps are gonna steal! Not sure if this is issue/concern is actually meaningful in the sense that the package *is very* useful, but... yeah.
[aur-general] Request to be maintainer of AUR package 'gimp-light'
The package gimp-light in the AUR has been left abandoned for over a year. I have written an updated PKGBUILD for 2.8.10, so wondered if the package could be orphaned so that I can take over as the maintainer? (The current maintainer seems to have disappeared)
Re: [aur-general] Package orphaning policy improvement - RFC
As a newcomer to packaging for the AUR, that was one of the things I thought I wonder why they don't do that already I'd read about some September cleanups (2011/2012 only?). Also, how about if orphaned for more than 3 months, then delete? There are some really outdated packages on there! On 25 May 2014 16:06, Nowaker enwuk...@gmail.com wrote: Hey, Currently one has to contact the maintainer and wait 2 weeks before reaching a TU on the ML to take over the package. I think this is totally OK when the maintainer really maintains the package, e.g. has generally frequent updates, responds to the comments, etc. However, this is an overhead when it's obvious a package is no longer maintained. For example, those marked out-of-date for more than 3 months, or those that have numbers of comments requesting update with no single response from the maintainer. It includes a situation when a maintainer is otherwise active on AUR, e.g. they update their other packages. The fact is they don't upgrade the very one package that people are interested in - otherwise a package wouldn't have been marked out-of-date in the first place. What do you think about auto-orhpaning packages that stay marked out-of-date for more than, say, 3 months? Done automatically by AUR, with no request on ML. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
