[aur-general] projectm packages in AUR
Hello, I am the maintainer for two projectm packages in the AUR, namely projectm-jack and projectm-libvisual-alsa. I think it would be best if these were also included in the split PKGBUILD for projectm related packages in the official repos. I see no reason to keep them separate in the AUR. P.S. I see that projectm-jack is now in the repos. Should I drop a message on the AUR mailing list to have that merged? P.P.S. I tried putting this in arch-dev-public, but it's not open for comment to the public it seems. I'm not entirely sure where to direct this, but since it is sort of related to the AUR, here seemed like a possibility. Allen
[aur-general] Merge request: projectm-jack
It is possible to merge projectm-jack in the AUR with the one in community? I am the maintainer for the package in the AUR, and there's no need for it anymore since it is in community. Allen
Re: [aur-general] Merge request: projectm-jack
On Sun, Nov 03, 2013 at 03:21:54PM +0800, Rashif Ray Rahman wrote: > On 3 November 2013 12:02, Allen Li wrote: > > It is possible to merge projectm-jack in the AUR with the one in > > community? I am the maintainer for the package in the AUR, and there's > > no need for it anymore since it is in community. > > > > Allen > > File a feature request at our bugtracker. Sorry, for some reason this seemed ambiguous to me. Do you mean file a request for the merge, or file a request for the feature to be able to merge AUR packages into repo packages? I thought the former, but I'm not sure now...
[aur-general] Duplicate packages
I just noticed that there are three packages for The Dark Mod game in the AUR: darkmod, v2.00-1, maintainer caemir doom3-darkmod, v1.08-1, orphan thedarkmod, v2.0-4, maintainer naelstrof Do we have a policy for handling such situations? It seems like it would be in everyone's best interests to merge into one package to minimize maintenance costs. Allen
[aur-general] Disown package android-4.0.3
Hi, Can someone disown android-4.0.3? It has not been updated in two years and needs its PKGBUILD fixed. I have tried emailing the current maintainer, zertyz, but my email bounced with the message below, so I think it would be okay to forgo the two weeks notice as there isn't a way to reach him/her. Allen Caro Internauta, Você enviou uma mensagem para um email que não é mais lido há anos -- FAVOR REENVIÁ-LA PARA O EMAIL CORRETO. Se não souber, me telefona e pergunta ;) Bjs e abçs e obrigado pela atenção!
[aur-general] Merge packages
mysql-connector-python can be merged into python-mysql-connector, since they are the same package, but python-mysql-connector is named properly, and mysql-connector-python is out of date.
Re: [aur-general] Remove python3-aur
On Sat, Mar 29, 2014 at 05:53:08PM +, xantares 09 wrote: > > > Date: Sat, 29 Mar 2014 12:59:08 + > > From: x...@archlinux.ca > > To: aur-general@archlinux.org > > Subject: Re: [aur-general] Remove python3-aur > > > > I have no intention of playing whack-a-mole with Python package names > > whenever > > Python gets around to the next major version bump even if that is years > > away. > > Each major version is incompatible with the previous ones and should > > therefore > > be treated as a separate language. Changing the names leads to transition > > periods of broken dependency graphs. Package names should be static and > > future > > proof. This makes it easier for everyone involved (developers, packagers, > > users). > > > > There are numerous python3-* packages that have peacefully existed in the > > AUR > > for years without issue. As I have so far been unable to convince others of > > the > > value of persistent naming, I prefer to leave things as they are. > > > > Regards, > > Xyne > > I wouldn't go as far as qualifying python3 a different laguage. It may > introduce api breakage, But it's possible to adapt the same codebase to be > compatible with both versions. > > They are some python3-* packages, yes, but they mostly belong to you :! > > What do we do from here ? Remove python-aur :? > > Regards, > xan. > I don't see any problem with leaving them as python3-*. In my mind, python2-*, python3-* are unambiguously named, and python-* merely refers to the "current stable". However, I have seen python-* refer to both python2 and python3, depending on how old the package or upstream is. I think the best policy would be to change python-* to python2-* when that disambiguation is necessary, and let python3-* well enough alone. They clearly describe the package, so what's the problem? Allen
Re: [aur-general] April Fools' Day jokes in AUR
On Tue, Apr 01, 2014 at 08:27:57PM +0200, Lukas Jirkovsky wrote:
> I feel that this PKGBUILD needs to be preserved for future generations
> after it has been deleted from AUR:
>
> pkgname=secure-certificates
> pkgver=0
> pkgrel=0
> pkgdesc="Trust no one"
> arch=(any)
> license=('WTFPL')
> url=('https://127.0.0.1')
> conflicts=('ca-certificates')
> provides=('ca-certificates')
>
> build() {
> echo "diy or die!"
> }
>
> package() {
> echo "nothing to do here too"
> }
+0
Not sure how to feel about this. On one hand, this is harmless and fun.
On the other, I don't think precedence for keeping joke packages on the
AUR is good.
[aur-general] Merge Request
Please merge python-pytagcloud into python2-pytagcloud. https://aur.archlinux.org/packages/python2-pytagcloud/ https://aur.archlinux.org/packages/python-pytagcloud/
[aur-general] Merge gvim-python with gvim-python3 in [extra]
Hello, I'm the maintainer for gvim-python. Can someone merge/delete it as there is now a package in [extra], gvim-python3? Thanks! [1]: https://aur.archlinux.org/packages/gvim-python/ [2]: https://www.archlinux.org/packages/extra/i686/gvim-python3/ [3]: https://www.archlinux.org/packages/extra/x86_64/gvim-python3/ pgpbYOceYJtX7.pgp Description: PGP signature
[aur-general] Merge ronn into ruby-ronn
Please merge ronn into ruby-ronn. [1]: https://aur.archlinux.org/packages/ronn/ [2]: https://aur.archlinux.org/packages/ruby-ronn/ pgpCgmQbAzOq8.pgp Description: PGP signature
[aur-general] Merge request: pyglet-hg and python-pyglet-hg
Hi, Please merge pyglet-hg [1] into python-pyglet-hg [2] Pyglet is a Python library, so it should have the python- prefix. Disclaimer: I'm the maintainer for python-pyglet-hg, and I stole some of lubosz's PKGBUILD and updated mine. P.S. I had a hell of a time getting the permissions right manually so the new AUR would accept it. Would this be a bug in mkaurball? [1]: https://aur.archlinux.org/packages/pyglet-hg/ [2]: https://aur.archlinux.org/packages/python-pyglet-hg/ pgpsfOsPy4Ql2.pgp Description: PGP signature
Re: [aur-general] Multiple packages removal request
Do they work? If the packages work, they should be kept, even if they are "useless" as you say, because someone may well find them useful for one purpose or another. On Tue, Sep 09, 2014 at 08:46:53PM +0400, wrote: > Please delete all ruby1.9* packages except for "ruby1.9-bundler" and > "ruby1.9". > > I am the maintainer of them all. > > I was going to use them as dependencies for metasploit-git package, > but I figured out creating a package for Metasploit is impossible. > Thus, I updated the wiki with manual install instructions: > https://wiki.archlinux.org/index.php?title=Metasploit_Framework&action=edit§ion=1#Installation > Now the packages I created are useless. pgpOmO2jbGjC3.pgp Description: PGP signature
Re: [aur-general] [PRQ#1823] Request Rejected
This probably belongs better on aur-general, so I've reposted it here. On Thu, Jan 01, 2015 at 04:09:12AM +0100, Stefan Husmann wrote: > Am 31.12.2014 um 10:34 schrieb not...@aur.archlinux.org: > > Request #1823 has been rejected by Barthalion [1]: > > > > It is not a reason for deletion. > > > > [1] https://aur.archlinux.org/account/Barthalion/ > > > > > I wonder what is a valid reason then. The Arch Packaging > standards clearly state which directories to use and which not. > Do we allow packages that wirte to /home then? > > The websitebacker PKGBUILD installs _all_ files to /srv. Other > packages got pruned because they install one file to /home. The proper way to do this is to install to /usr/share/webapps, and then configure it to be served by Apache/nginx. Installing to /srv is definitely not encouraged. However, I don't know if that is enough to justify deletion. Generally, packages are only deleted if they are absolutely unuseable, completely malicious, etc. because even if the package is broken, someone else can update or fix the PKGBUILD in the future. pgpB4urW2phf5.pgp Description: PGP signature
Re: [aur-general] Merging ruby-jekyll into a single package
One problem is that the different gems have different upstream versions (ruby-jekyll 2.5.3, ruby-jekyll paginate 1.1.0, etc). However, ruby-jekyll should definitely depend on all of its dependencies, which it does not do currently. Hugo Osvaldo Barrera writes: > Hi there! > > Jekyll is currently a bit of a mess on the AUR. There's packages for several > "plugins", like ruby-jekyll-pagination, and several others. > > However, these are not plugins in the traditional sense of the word: jekyll > won't run if they're not installed, so they're more like libraries. Libraries > that are only used inside jekyll and are not designed to be used > independently. > > So there's very strong codependency. ruby-jekyll-pagination and ruby-jekyll > end up depending on each other mutually. Again, "-pagination" is merely an > example, there's plenty of these. > > Someone suggested merging these into a single package: they're diferente > upstream gems, but only work in unison, and are useless separately, so I'm > inclined to simplify this on our side (KISS, right?). > > Would this course of action be deemed appropriate? Is it acceptable? I know we > usually don't bundle stuff like this in AUR, but this seems like a strong > exception, since we're talking about packages with mutual codependency. > > Thoughts? Opinions?
Re: [aur-general] Orphan request
> > > Op zondag 15 juli 2012 21:46:08 schreef D. Can Celasun: > > >> Wow, Déjà vu! In the past another TU asked me the exact same question > > >> and it was decided that if the maintainer didn't update any of his > > >> packages for a long time (e.g a year) the wait-2-weeks-for-response > > >> wasn't necessary. That particular discussion is here [1]. So I'd be > > >> glad if you could go ahead and orphan the packages. > > >> > > >> Thanks! > > >> > > >> [1] > > >> http://mailman.archlinux.org/pipermail/aur-general/2011-October/016307.ht > > >> ml Now, I don't know what official rules we have, but I don't think this is right. Sometimes, a package may be stable without being updated upstream for a long time, and suddenly it's updated a year or so later, and the maintainer may be active but unaware of this. A friendly email reminder should be the first step, and only if the maintainer doesn't respond then a TU should orphan. Am I wrong? Allen Li
Re: [aur-general] Orphan request
On Mon, Jul 16, 2012 at 11:00:21PM +0300, D. Can Celasun wrote: > On Mon, Jul 16, 2012 at 10:53 PM, Allen Li wrote: > >> > > Op zondag 15 juli 2012 21:46:08 schreef D. Can Celasun: > >> > >> Wow, Déją vu! In the past another TU asked me the exact same question > >> > >> and it was decided that if the maintainer didn't update any of his > >> > >> packages for a long time (e.g a year) the wait-2-weeks-for-response > >> > >> wasn't necessary. That particular discussion is here [1]. So I'd be > >> > >> glad if you could go ahead and orphan the packages. > >> > >> > >> > >> Thanks! > >> > >> > >> > >> [1] > >> > >> http://mailman.archlinux.org/pipermail/aur-general/2011-October/016307.ht > >> > >> ml > > > > Now, I don't know what official rules we have, but I don't think this is > > right. > > Sometimes, a package may be stable without being updated upstream for a long > > time, and suddenly it's updated a year or so later, and the maintainer may > > be > > active but unaware of this. A friendly email reminder should be the first > > step, and only if the maintainer doesn't respond then a TU should orphan. > > Am I > > wrong? > > > > Allen Li > > > Well, in the case of these two packages (and the one mentioned in the > other thread), there were several considerations to counter your > points. The packages: > > - Had more recent upstream stable versions for a long time, > - Have been flagged as out-of-date for a long time, > - Had several up-to-date PKGBUILDs in the comments without any input > from the maintainer. > > Furthermore, the maintainer didn't update *any* of his packages in > more than a year. So in the end, I don't think your reasoning should > apply to cases like this. Am I wrong? > > Can Yes, I agree that in this situation orphaning is the right choice. I didn't look at the details, but from the email it appeared to suggest a "No update in one year = instant orphan" precedent, which I'm sure you agree is a bad idea. Sorry for any misunderstandings. Allen
[aur-general] Deletion request
Hi, Could someone delete python-spynner? The official download from pypi has been down for a while now. I've uploaded python2-spynner-git which uses the development version. If and when the official download comes back, I'll reupload as python2-spynner as per proper naming conventions. Allen Li
Re: [aur-general] ibus orphans in [community]
Hi, I would like to point out that ibus does Japanese and Korean, whereas fcitx only does simplified Chinese (at least according to the wiki). Thus ibus is one of the only input options for those languages on arch at the moment (barring that other one whose name I'm having trouble recalling at the moment, which I found inferior to ibus), so dropping it is extremely unfavorable I think. Just my two cents. Allen Li On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: > Hello, > > > ibus is used for keyboard input for a few major non-English languages. > > Several of the ibus packages has been unmaintained for a while now: > https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan > For instance, ibus-sunpinyin, was last updated almost a year ago (2011-10-02). > > These ibus-packages have survived at least one package-cleanup, being > neither adopted nor moved. > While there is interest amongst the trusted users to maintain these, > none of the trusted users are currently using ibus. > > After visiting #archlinux-cn, a couple of friendly people expressed > interest in maintaining the ibus packages, but they had only few > packages on AUR to show for. > I also learned that mostly, fcitx (currently in [extra], is used > instead of ibus). Dropping ibus could have been an option, but I also > heard rumors that ibus will be a dependency of gnome-settings-daemon. > > There is also a canidate for asking to maintain the ibus packages, > that has not yet been contacted, but which already maintains several > related packages on AUR: > https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m > > If you think that his packages look ok, my plan is to contact > yangtsesu and ask if he wants to maintain the ibus packages in > [community] (and thus becoming a TU). > > If you know of other canidates that have a comparable selection of > relevant AUR packages, please let us know who they are. > > Please correct me if any of the above is incorrect or let us know if > you have additional information. > > Sounds like a plan? > > > -- > Cordially, > Alexander Rødseth > Arch Linux Trusted User > (xyproto on IRC, trontonic on AUR)
Re: [aur-general] ibus orphans in [community]
On Thu, 18 Oct 2012 17:45:51 +0200 Alexander Rødseth wrote: > If I understand it correctly, we _could_ drop ibus and just use fcitx > instead, but supporting ibus as well is preferrable, since many people > also use ibus. My gripe with fcitx is that it is poorly documented (in English at least), and I wasn't able to get it to work. I'm sure people are using it fine, but I feel that the quality of software is limited by its documentation. No documentation = software sucks, end of story. If we move in this direction, I'd like to see someone familiar with fcitx update the wiki accordingly =). Allen Li
[aur-general] Naming convention for Python 2 and 3 apps
Hi everybody, I know that the naming convention for python libraries is python(2)-*, but do we have a convention for python applications installed for different python versions? The package in question is flake8, which can be installed for both Python 2 and 3. Allen Li
Re: [aur-general] Naming convention for Python 2 and 3 apps
On Tue, Nov 27, 2012 at 07:43:07PM -0500, Yichao Yu wrote: > On Tue, Nov 27, 2012 at 2:48 PM, 小龙 陈 wrote: > > Hi Allen, > > > > I think the convention is to make two packages for software that > > support both Python 2 and 3. For example, in the extra repo, there's > > > > python-cairo and python2-cairo > > python-cchardet and python2-cchardet > > python-memcached and python2-memcached > > etc. > > Well, both of them are python libraries, which cannot support both > python2 and python3 in the same binary package (OK, you can, by > including both python2 and python3 modules but that's not the > point) > > According to a previous email on the same list[1], you probably still > need to create two packages for pyton2 and python3 if you want to > support both of them (and probably rename the binary to avoid > conflict.) > > [1] http://www.mail-archive.com/aur-general@archlinux.org/msg19241.html Well, the problem is flake8 is a python app, not a library. Maybe I'm worrying about nothing, but should the python-*, python2-* naming convention also be used in this case?
Re: [aur-general] Naming convention for Python 2 and 3 apps
On Wed, Nov 28, 2012 at 07:07:27AM -0500, Stéphane Gaudreault wrote: > If it is an application and does not provide a module that could be > included in another application, then I suggest to depend on python3 > only and keep the name "flake8". > > Stéphane > That sounds reasonable enough, but I think we'll still need separate versions here. flake8 is a code checker, and it seems to run into trouble between Python 2 and 3 code since it runs the code when checking it. Backward incompatibility is troublesome. *-python is no good since it looks like it's used for Python APIs and hooks.
Re: [aur-general] Naming convention for Python 2 and 3 apps
On Thu, Nov 29, 2012 at 04:58:28AM +, Xyne wrote: > Use "flake8" (Python 3) and "python2-flake8". If you cannot rename the > installed > files in python2-flake8 to avoid conflicts, add a "conflict=(python8)" to the > PKGBUILD. > > In general the "python*-" prefix is reserved for library packages, but its > real > purpose (imo) is simply to indicate that a package is closely tied to some > version of Python. > > > While we're on the subject, can someone please explain to me again why we use > "python-" and not "python3-" for Python 3 libraries? > > Regards, > Xyne Thanks, that makes sense. I believe it's because Python 3 is now considered the "default" python installation, while Python 2 is a specific version. It's the same reason Python 3 is python and Python 2 is python2 in the repo. Although there are quite a few Python 2 packages both in the official repos and on the AUR that use "python-*", I suppose no one can be buggered to fix it. Allen
Re: [aur-general] Naming convention for Python 2 and 3 apps
On Tue, Dec 11, 2012 at 12:52:12AM +0100, Karol Woźniak wrote: > It seems that none cares after all, huh? > But I still do want to do it as right as it can possibly be, mostly because > I now need flake8 for both python 2 and 3. > So if nobody complains, I'll go with my initial thought (see my previous > post here) sometime near the end of the week. I think flake8, python2-flake8 for the package names and flake8, flake82 for the executables is fine. flake82 looks a little unwieldy, but I don't think there's anything fundamentally wrong with that name. Maybe include a note in the .install or somewhere so that users know that it has been renamed. Someone else has picked up flake8-python3 since I orphaned it, so you may need to get him/her to drop it again. Allen
Re: [aur-general] Compiling with UTF-8 symbols in build path
On Thu, Dec 20, 2012 at 11:12:35AM +0100, Paul Weingardt wrote: > Here is the error message: > > Exception occurred: > File "/usr/lib/python2.7/site-packages/sphinx/environment.py", line 758, in > read_doc > pub.set_source(None, src_path.encode(fs_encoding)) > UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 25: > ordinal not in range(128) It looks like the error is occurring in sphinx, which is a Python library that builds the documentation. fs_encoding = ascii on his/her computer, it seems, so of course unicode in a path won't work. Maybe he/she should file a bug upstream? Allen
Re: [aur-general] Suggestions for dealing with packages that require root
On Thu, Dec 20, 2012 at 07:01:21AM -0500, Dave Reisner wrote: > To the OP, I suggest finding out what legitimately fails in the build when > the user doesn't exist and patching the build system to suck less. When > you're done, send your improvements upstream. My suggestion would be to simply fail out if the user doesn't exist and have the user create the user himself. (Include the "sudo adduser something" that needs to be run in the error message for simplicity). AUR isn't supposed to be simple as in newbie-friendly but simple as in without cruft. Just my two cents. Allen
Re: [aur-general] Best Practice for switching packages from svn to git
On Fri, Jan 11, 2013 at 11:30:02AM +0100, Christoph Vigano wrote:
> Hey everybody,
>
> I'm in the situation that one of my packages switched their VCS from SVN
> to Git. Is it okay to conflict both the non-SVN and the SVN package at
> the same time?
>
> The package in question is nagstamon-svn, whose upstream made the change
> to Git. I want to use the following lines in the PKGBUILD:
>
> provides=('nagstamon')
> conflicts=('nagstamon' 'nagstamon-svn').
>
> Any opinions towards this?
>
> Greetings,
> Christoph
>
I'm not sure what exactly you're saying. If nagstamon-svn and
nagstamon-git both conflicts=('nagstamon'),
P.S. a question I thought of just now. Does listing a package in
conflicts automatically add it to provides? I think I've seen/written
git packages with only a conflicts, but it satisfies dependencies all
the same.
Re: [aur-general] [removal] Projectm-pulseaudio and projectm-qt
On Wed, Feb 20, 2013 at 10:39:13AM +0800, Felix Yan wrote: > On Tuesday, February 19, 2013 21:59:46 Denis A. Altoé Falqueto wrote: > > Guys, > > > > Those two packages are provided by community as of today, thanks to > > Alexander Rødseth, who is the new maintainer of projectm. They're > > being built as a split package from projectm. > > > > projectm-pulseaudio: > > https://aur.archlinux.org/packages/projectm-pulseaudio/ > > projectm-qt: > > https://aur.archlinux.org/packages/projectm-qt/ > Both removed, thanks. I'm guessing projectm-jack was also removed alongside these, however, the split PKGBUILD for projectm in community doesn't actually provide projectm-jack. I'll be reuploading projectm-jack, if there are no objections? Allen Li
Re: [aur-general] User ban request --- can I get a response, please?
On Tue, Mar 05, 2013 at 11:30:05PM -0500, Limao Luo wrote: >On 03/05/2013 11:21 PM, William Giokas wrote: >>Captchas, man. Captchas. I know it will very very slightly inconvenience >>some people that have to flag a few packages out of date at a time, but >>really, it would only save us from crap like this. >> >Yeah, they mentioned that in the aur-dev conversation, among other >ideas like IP blocking (which actually sounds good, except more than >one person can have an IP, so I don't know how much that would work, >unless there is some timeout period or something for the block) and >repeatedly doubling intervals after successive flags that time out >after an hour (which, while annoying, doesn't seem like an enough of >a deterrent, but I could be wrong). > >Well, not much to do except wait it out, I guess. I just can't >remember which packages I have to update now. Instead of captchas for flagging packages, do we have captchas for creating new accounts already? That seems more sensible. Also, perhaps blocking new accounts using disposable emails, at least temporarily? Allen Li
Re: [aur-general] Fighting spam on the AUR
On Wed, Mar 13, 2013 at 11:55:26AM +0100, Markus Unterwaditzer wrote: > Other options: > > * Deny the repeating of a specific action... e.g. you may not flag more than > ten packages within ten minutes. Also block comments with same content. > > * ability to report users (dunno if already possible), autoban if enough > reports > > * "Buffering actions" aka shadowban when a user gets reported, until a > moderator reviews the report. > > * Do whatever Reddit does, they seem to deal very well with spam. > > -- Markus (from phone) Absolutely not the autoban, then spammers could *REALLY* do some damage. I am personally for a simple registration captcha. I doubt any spammers targeting the AUR are really invested; it's not really a high-profile target, most likely some pranksters, so a simple captcha could really help weed them out. How about implementing a registration captcha and seeing how it works before considering more complex options? Limiting repeated actions also sounds good (if someone really needs to, e.g., flag a lot of packages, they can just drop a request here and let a TU handle it), but it doesn't really stop spammers. They'll just make more accounts. Allen
Re: [aur-general] Strange filesystem conflict behavior
On Mon, Mar 25, 2013 at 05:49:55PM -0400, Kyle wrote: > Today I upgraded my espeak-test package in AUR from 1.46.53 to the > latest 1.47.03b. However, while testing my PKGBUILD, I received a file > conflict error when attempting to install the binary package using > pacman -U. It seems that /usr/share/espeak-data/voices/en, which is a > directory in previous versions of espeak-test as well as > community/espeak, has become a voice definition file in 1.47.03b. > Apparently, this causes a file conflict error to be raised by pacman > during the installation attempt. For now, I have added a comment to the > AUR page informing anyone using the package that they should remove the > entire /usr/share/espeak-data directory prior to installing the newest > espeak-test, since --force should never be used for this kind of thing, > and this removal is what I needed to do to get the new package > installed. The question is whether or not this was the correct action to > take, or if anyone has suggestions for truly fixing the problem. I am > also wondering at this point if I have found a bug in pacman that would > be causing this conflict error to be raised, in spite of the fact that I > have added the proper conflicts and provides fields hat should have kept > such an error from occurring. Thanks very much for any help. > ~Kyle > http://kyle.tk/-- > "Kyle? ... She calls her cake, Kyle?" > Out of This World, season 2 episode 21 - "The Amazing Evie" Can't you just uninstall the previous version before installing the newer version? No need to manually remove anything. Allen
Re: [aur-general] Make AUR notifier messages more visible
On Mon, Apr 15, 2013 at 09:08:52AM -0700, Anatol Pomozov wrote: > Hi, > > On Mon, Apr 15, 2013 at 8:50 AM, Chris “Kwpolska” Warrick > > > > Just do a goddamn filter in Gmail. > > Yes I am aware of filters (I worked in Gmail UI team btw). I already > have 300+ filters and I hate to add more, especially for one-time > notifications. > > Forcing everyone to create a filter for aur notifications sounds wrong > to me. Most people just will not do this. And I think "invisible" > message by default + people's laziness to create filters is the reason > why it is more difficult to get a package maintainer response via > comments rather than via personal email. > > Most web sites (such as forums) known to me send notifications "to:" > user exactly for this reason - make these messages visible by default. I personally don't have any objections either way, but is there a reason *not* to send notifications directly to the user? Sure, there are ways around it (filters for Gmail) , but why make it an issue in the first place? Just my $0.02 Allen
[aur-general] Original vlock sources
Hello fellow Archers, Does anyone by any chance have the original vlock source code? A while back, community/vlock was taken in by core/kbd because vlock upstream was dead. This should have been a good thing, but it is not a good thing because the kbd version of vlock is missing important features. And now when I try to find the original, surprise, the sources are gone. Thanks, Allen
Re: [aur-general] Original vlock sources
On Sun, Jul 28, 2013 at 04:19:12PM -0400, Dave Reisner wrote: > What features are missing? Why not contact the Altlinux folks who > maintain kbd and discuss how they can be re-added? The -n and -s options that allow vlock to be used within an X session to lock all consoles. This has already been discussed on the kbd mailing list. See [1]. Alexey's stance seems to be kbd's vlock is not intended to replace the vlock that has these features. So it is the fault of the official repo maintainers who deprecated community/vlock. This has also been discussed on arch-general as well [2]. Seems like their opinion is to request upstream. So both arch-general and upstream push the responsibility to the other party. That is why I'd like a copy of the sources. Depending on the license, if any, I'll put a copy on Github and add a package on AUR to put an end to this nonsense. Allen [1] http://lists.altlinux.org/pipermail/kbd/2013-January/000388.html [2] https://mailman.archlinux.org/pipermail/arch-general/2013-January/032771.html
[aur-general] Removal request: stone-soup-tile05
stone-soup-tile05 It's extremely out of date and orphaned. stone-soup is in community and also includes tiles, so I see no reason for this to still exist. Allen Li
