[aur-general] Advise on updating/uploading binary package

[Oon-Ee Ng via aur-general]

I've been using cin-git for a while (which draws on cinelerra-gg project).
For those who are unfamiliar, there's the 'original' (old and out-of-date)
cinelerra, and a newer cinelerra-heroine, and the most popular one is
cinelerra-gg.

The 'cin-bin' PKGBUILD on AUR points to the original website, and is
practically useless in an up-to-date Arch system. For convenience (and
because recently some problems have been happening with cin-git), I want to
upload a binary verison of cinelerra-gg. As cin-bin is currently quite
useless (and IMO the -gg project is the real heir of the cinelerra
heritage), is there any reason I shouldn't adopt it and update it to point
to cinelerra-gg binary package?

Re: [aur-general] Spammy post on cntlm's AUR page

[Oon-Ee Ng via aur-general]

Exactly the same comment has been repeated, this time by user
https://aur.archlinux.org/account/KennethMicha

Seems very targetted, and I wonder why that would be.

On Fri, May 3, 2019 at 4:16 AM Robin Broda via aur-general <
aur-general@archlinux.org> wrote:

> On 5/2/19 10:11 PM, Oon-Ee Ng via aur-general wrote:
> > Latest post, the only one by this account -
> > https://aur.archlinux.org/account/RonaldSteele - post unrelated to other
> > comments on cntlm and links to dodgy blog.
> >
> > Account just registered today. Surprised there's only one post so far.
> >
>
> Comment removed & account suspended indefinitely.
>
> Thanks for the report
>
> --
> Rob (coderobe)
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>
>

[aur-general] Spammy post on cntlm's AUR page

[Oon-Ee Ng via aur-general]

Latest post, the only one by this account -
https://aur.archlinux.org/account/RonaldSteele - post unrelated to other
comments on cntlm and links to dodgy blog.

Account just registered today. Surprised there's only one post so far.

Re: [aur-general] On TU application, TU participation and community/ package quality

[Oon-Ee Ng via aur-general]

Third-party non-involved user chiming in, but I do not think any sort of
tenure/seniority requirement as mentioned in the final point below would be
a good idea. Something based on recent activity would be better.

On Wed, Nov 28, 2018 at 1:38 AM Bruno Pagani via aur-general <
aur-general@archlinux.org> wrote:

> Le 27/11/2018 à 16:32, Santiago Torres-Arias via aur-general a écrit :
> > On Sun, Nov 11, 2018 at 01:29:31PM -0500, Santiago Torres-Arias via
> aur-general wrote:
> >> On TU applications, TU participation and package quality:
> >> everythign snipped
> > I just wanted to bump this thread.
> >
> > It appears to me that bumping the minimum number of TU sponsors + a
> > buddy system would be the way to go?
> >
> > Should we move on to formalize this?
> >
> > Thanks,
> > -Santiago.
>
> I like part of Xyne ideas, that finally are just what good common sense
> should be:
>
> – The need to know who you sponsor a while before letting them apply;
> – The need to advocate for your candidate;
> – The need of several sponsors (maybe 2 should be enough if they are
> well chosen), but I would say beforehand, in order to have at least 2
> reviews of the applicant PKGBUILDs before actually applying. And one of
> the sponsors should have been there for at least some years (not sure
> what would be a good number, 3, 5?).
>
> Regards,
> Bruno
>
>
>

Re: [aur-general] Could someone please bring back the skypeforlinux-beta-bin package?

[Oon-Ee Ng via aur-general]

On Mon, Nov 13, 2017 at 10:51 PM, Eli Schwartz 
wrote:

> On 11/13/2017 09:35 AM, Michael Kogan wrote:
> > @1) Sorry, I am using the GMail web interface and forgot that it is
> quoting
> > previous mails automatically.
>
> I feel so sorry for you! :D I hope you have the opportunity to get back
> to using a proper email client soon. :)
>
> It's actually a fantastic email client for those of us who transition
often between devices and operating systems. Obviously for mailing list
usage its less than ideal though (until you get used to clicking that
three-dot button)

Re: [aur-general] Suggestion to add a pinned comment to PKGBUILDs of high risk vulnerable software

[Oon-Ee Ng via aur-general]

On Tue, Jul 4, 2017 at 1:47 PM, Ralf Mardorf 
wrote:

> On Tue, 4 Jul 2017 13:25:09 +0800, Oon-Ee Ng via aur-general wrote:
> >This is the primary question here. If it's the maintainer then... what
> >is this email thread even for?
>
> It's about sense of responsibility. As already pointed out,
> something like the webkit PKGBUILDs are objectively PKGBUILDs with a
> very serious high security risk. Users might not be aware of it,
> they might think it's software, that was dropped from official
> repositories for harmless maintenance issues. For example, a Heartbleed
> affected SSL is not the same as an discontinued Sudoko game without
> internet access, even if such a Sudoko game might come with
> minor security issues, too.
>

And as you've already pointed out, this is the responsibility of the
maintainer. You could suggest it on the package's AUR page.

By sending it to the ML, it looks like you're trying to discuss or push for
a general decision. That's not going to happen on this issue, I don't
think.

Re: [aur-general] Suggestion to add a pinned comment to PKGBUILDs of high risk vulnerable software

[Oon-Ee Ng via aur-general]

On Sun, Jul 2, 2017 at 4:56 PM, Ralf Mardorf 
wrote:

> On Sun, 2 Jul 2017 03:49:10 -0400, Eli Schwartz via aur-general wrote:
>
> >Even if it weren't entirely up to the maintainer to pin comments, who
> >are you proposing should be responsible for determining what packages
> >should come with warnings, and then providing such warnings?
>

This is the primary question here. If it's the maintainer then... what is
this email thread even for?

Re: [aur-general] aurweb 4.0.0 released

[Oon-Ee Ng]

On Tue, Aug 11, 2015 at 11:31 AM, Giancarlo Razzolini
 wrote:

> orphan and unmaintained packages anyway. I guess that if all of the Arch
> users didn't needed them in more than the two months that it took to
> migrate AUR3 to AUR4, it is a safe bet to say that there won't be much
> use for them in the near future. And, if there is an unofficial archive,


Just to note on this point - some (many?) Arch users would not have
noticed anything during the migration process as their helpers would
have continued to get the old PKGBUILDs from aur.archlinux.org during
the migration process. It is only when aur4 got 'moved' to
aur.archlinux.org that these users would have noticed anything happen
(in fact some still won't, depending on their workflow and the
specific tools they use).

I have no opinion in either case, PKGBUILDs aren't THAT difficult to
write, but felt I had to point this out.

Re: [aur-general] We've got a spam issue in our AUR

[Oon-Ee Ng]

On Tue, Jul 14, 2015 at 3:43 AM, Johannes Löthberg
 wrote:
> Not all spam is automated , so just requiring a CAPTCHA wouldn't be very
> useful. I think a slightly better approach would be to add the comment to a
> queue if it fails the spam filter, and require a TU to approve it.

Seems like a lot of unnecessary work for TUs though. Maybe it would be
better for maintainers approval to be required for posts that fail a
spam filter (they could just ignore it). Even if its not really spam,
its probably aimed at the maintainer anyway.

[aur-general] Should I request deletion for packages in this transition period?

[Oon-Ee Ng]

I'm only now looking at the AUR4 migration guidelines, and I only have
a few packages so I've been uploading to AUR4 manually.

However, in the process I've found old packages which I no longer use
or wish to maintain. Some of which should may be deletion candidates.

Of course, those all belong to me and hence aren't (yet) in AUR4. The
announcement email I got stated that after August 8th all packages in
the AUR will remain archived for reference. Should I request a
deletion before that (for those packages which it really does not make
sense to keep around) to reduce clutter, or will it really not make a
difference?

Re: [aur-general] Trusted User application: Levente Polyak

[Oon-Ee Ng]

On Fri, Mar 20, 2015 at 1:05 AM, Levente Polyak  wrote:
>
> On top of this I also had a look at the currently orphaned packages in
> [community] and I would like to adopt the following packages: ansible,
> awesome, cclive, codeblocks, fail2ban, fish, ncmpcpp, id3v2.

Adopting awesome? Yes please!

Re: [aur-general] Discussion about AUR packages signing

[Oon-Ee Ng]

On Fri, Aug 8, 2014 at 10:06 AM, Dave Reisner  wrote:
> On Thu, Aug 07, 2014 at 09:57:24PM +0200, Fabien Dubosson wrote:
>> Hi,
>>
>> I want to start a discussion about AUR packages signing. If this debate
>> already happened, it means that I'm not really good with Google or
>> unfortunate in the keywords I used in my searches: in these cases
>> forgive me and just give me some pointers.
>>
>> TL;DR I personally "trust" some AUR users who have several good-quality
>>   packages, and an optional way to sign AUR packages would permit me
>>   to know that I can build and update their packages without
>>   worrying too much.
>
> I did read your proposal, but my comment can be framed in the context of
> your tl;dr:
>
> You don't really seem to want GPG signatures, just a whitelist of
> package maintainers by name. Any AUR helper could implement support for
> this today, with no changes to the AUR.

Which reminds me of the old bauerbill Xyne wrote, which did precisely that =)

Re: [aur-general] Delete request: python34

[Oon-Ee Ng]

On Fri, Mar 21, 2014 at 1:54 AM, Felix Yan  wrote:
> On Thursday, March 20, 2014 16:37:42 Jerome Leclanche wrote:
>> It is with great joy that I'm requesting the deletion of this package,
>> as it's now available as community/python.
>>
>> https://aur.archlinux.org/packages/python34/
>>
>> J. Leclanche
>
> Removed, thanks :)


I hate being 'that guy', but shouldn't deletion wait till it goes into
[extra]? Unless we're assuming that the set of people using an AUR
package for the latest version of python is a subset of those using
[testing] =)

Re: [aur-general] Merging request.

[Oon-Ee Ng]

On 24 Aug 2013 07:23, "William Gathoye"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi guys,
>
> >> Could elementary-icons-bzr be merged into
> >> elementary-icon-theme-bzr to be in sync with
> >> elementary-icon-theme from [community] ?
> >>
> >
> > Merged, thx.
> >
>
> Let me join the discussion here, as I'm concerned by this merge.
>
> I've installed the elementary-icons-bzr package a few days ago from
> the AUR repository. After the merge to elementary-icon-theme-bzr
> occurred, with the current AUR implementation, the AUR helpers like
> yaourt cannot intercept a warning from the AUR stating that the
> package name has changed.
>
> It's a good thing I've subscribed to this mailing list and I'm reading
> all messages that transit via my mailbox. Without this subscription, I
> wouldn't have been aware of that name change and my package would
> remain installed and become outdated with time.
>
> Am I doing something wrong? How to prevent that to happen? Is there a
> tool to circumvent this AUR implementation problem?
>
It's not an implementation problem, it's a usage problem. If you subscribe
to notifications from the package you'd receive a notification. Good aur
tools can always alert you if the package is no longer found. Ask their
developers.

The aur is not supposed to be used as just another repository (like how
yaourt and Co pretend it is), more manual intervention is needed.

Re: [aur-general] google-earth - Integrity checks (md5) fail

[Oon-Ee Ng]

On Tue, Jul 16, 2013 at 10:53 PM, Alexander Rødseth  wrote:
>
>> Rarely, if ever, do people simply dump command output on aur-general and
>> expect anything to come of it. You're the minority.
>
> This is a logical fallacy and an appeal to popularity, this doesn't
> make him wrong. As a first-timer, how could he know that posting what
> he judged to be an issue, proved not to be an actual issue? It
> certainly was about the Arch User Repository.
>
> When applying some good will, I think it's clear that he thought he
> posted to the right communication channel. Even though his post
> contained no formal arguments, no single post can be a discussion in
> itself.
>
Fair enough but I would not call Ralf a first-timer perhaps to the
AUR list, but certainly not to Arch.

[aur-general] Remove request - magic-background

[Oon-Ee Ng]

Personal project of the author that he's lost the sources to
(confirmed via email conversation with him).

Please delete https://aur.archlinux.org/packages/magic-background/

Re: [aur-general] Please delete evolution-plugins-experimental

[Oon-Ee Ng]

On Wed, Jun 26, 2013 at 7:47 AM, Evangelos Foutras
 wrote:
> On 26 June 2013 02:41, Oon-Ee Ng  wrote:
>> https://aur.archlinux.org/packages/evolution-plugins-experimental/
>>
>> External Editior plugin is now enabled in evolution in the repos
>>
>> I'm the submitter and maintainer.
>
> Removed, thanks.

Thanks for the quick response. One less speck of dust on the AUR-mantle

[aur-general] Please delete evolution-plugins-experimental

[Oon-Ee Ng]

https://aur.archlinux.org/packages/evolution-plugins-experimental/

External Editior plugin is now enabled in evolution in the repos

I'm the submitter and maintainer.

Re: [aur-general] Unused account on BBS and AUR web interface

[Oon-Ee Ng]

On May 4, 2013 11:34 PM, "William Gathoye"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi guys,
>
> I would like to contribute to the AUR, but it appears the account
> 'wget' has already been registrered, but no one seems to currently use
> it. It looks like someone has asked for a password reset but hasn't
> clicked on the confirmation link from the email yet.
> Would it be possible for you to unlock this account and release this
> username for me?
>
> I'm experiencing the same issue with the BBS forum. I got 'Invalid
> username' as a response from the registration form.
>
> It would be nice if I could keep the same e-dentity for the ArchLinux
> community, as I'm using the same nickname for the communities where
> I'm getting involved in.
>
>
> Regards,
>
> - --
> William Gathoye
> 

For the forums, email an admin. I doubt you'll have much luck, invalid
username is probably a protective measure against very common names.

Re: [aur-general] iniparser moved to community?

[Oon-Ee Ng]

On Mon, Feb 25, 2013 at 5:40 PM, Barton  wrote:
> It seems that iniparser-git [1] has become iniparser [community] [2], but I
> could be wrong.
> The second has a more recent date on it.
> -barton
>
> [1] https://aur.archlinux.org/packages/iniparser-git/
> [2] https://www.archlinux.org/packages/?repo=Community&q=iniparser

-git packages are always built from source, the date it was last
updated is meaningless.

Re: [aur-general] Delete request: 2299thegame

[Oon-Ee Ng]

On Sun, Feb 17, 2013 at 2:55 PM, Limao Luo  wrote:
> I'm requesting deletion of my package 2299thegame [1] because the binary
> (from an older release) segfaults, there is no source I could find anywhere
> else, and even the original Realstudio source files cause a segfault when I
> open them in RealStudio to try to build a tar.

Realstudio is just segfaulting on everything nowadays (since maybe
half a year ago) in Arch (and later versions of Ubuntu, based on their
forums)

Re: [aur-general] TU Application

[Oon-Ee Ng]

On Fri, Feb 15, 2013 at 9:42 AM, Xyne  wrote:
> Daniel Micay wrote:
>
>>I'll even forgive you for being a closet iPhone user. >:)
>
> In light of this revelation and by section 5, subsection 3, paragraph 2 of the
> TU bylaws, I hereby move for summary rejection of this application.

Including and not limited to an immediate removal of posting
privileges from this and all other Arch-related mailing lists, the
Arch forums, and the Arch bug-tracker (Google+ and Facebook pages are
beyond the writ of said bylaws).

Re: [aur-general] NVIDIA drivers

[Oon-Ee Ng]

On Jan 27, 2013 4:59 AM, "Rob Til Freedmen" 
wrote:
>
>
> Maybe I'm missing something ... but what could possible go wrong
> if we go with "nvidia-utils" instead of "nvidia-utils=${pkgver}" ?
>
> There's only one package named nvidia-utils build from the same
> source and always updated in tandem in the repo.
>
> nvidia really only depends on the kernel header and nvidia-utils
> is build from the same source - depends on nvidia at build time.
>
> Please be patient with me, I don't get it yet.

AUR is not always in sync with the specific mirror you're using. Mirrors
sync at different times. Perhaps nvidia-utils could have a different
version in [testing].

Re: [aur-general] NVIDIA drivers

[Oon-Ee Ng]

On Jan 26, 2013 7:42 AM, "Maxime Gauduin"  wrote:
>
> On Fri, Jan 25, 2013 at 11:43 PM, Oon-Ee Ng 
wrote:
>
> > On Jan 26, 2013 6:10 AM, "Rob Til Freedmen" 
> > wrote:
> > >
> > > There is a dependency in nvidia/PKGBUILD which is totally wrong
> > > depends=( [...] "nvidia-utils=${pkgver}")
> > >
> > > It leads to a circular dependency at ***build*** time and isn't really
> > needed
> > > at run time for nvidia to work.
> > >
> > > depends=( [...] "nvidia-utils") should be enough to pull it in when
> > > installing/updating
> > >
> > > I've reported it last year but didn't got any response from the
> > maintainer.
> > >
> >
> > Have you tried installing different versions of nvidia-utils and nvidia?
> > There's a reason for that versions dependency.
> >
>
>
> I did once by mistake, that wasn't pretty. No the hard dependencies are
> required, the problem is the depends array implies makedepends, but
> sometimes it is wrong like here. Making depends and makedepends
> independent, then have makepkg check for depends only at install time
would
> make more sense. However that would mean a rewrite of these 2 arrays in
all
> the PKGBUILDs in the AUR, I don't see that happening.
>
If that makes sense I'm sure a feature request on pacman wouldn't be out of
place. Minimal benefit though, as this really only affects a handful of
packages. Doesn't makepkg have a flag to ignore dependencies? Arch laptop
died so I can't easily check, that would be easier on everyone involved
(except yaourt and similar users)

Re: [aur-general] NVIDIA drivers

[Oon-Ee Ng]

On Jan 26, 2013 6:10 AM, "Rob Til Freedmen" 
wrote:
>
> There is a dependency in nvidia/PKGBUILD which is totally wrong
> depends=( [...] "nvidia-utils=${pkgver}")
>
> It leads to a circular dependency at ***build*** time and isn't really
needed
> at run time for nvidia to work.
>
> depends=( [...] "nvidia-utils") should be enough to pull it in when
> installing/updating
>
> I've reported it last year but didn't got any response from the
maintainer.
>

Have you tried installing different versions of nvidia-utils and nvidia?
There's a reason for that versions dependency.

Re: [aur-general] NVIDIA drivers

[Oon-Ee Ng]

On Fri, Jan 25, 2013 at 9:32 AM, SpinFlo  wrote:
> i ve use yaourt, yes,
>
> yaourt when make and install sucessful package delete all sources.,
> then the symlink don't work

Don't use yaourt then.

On Fri, Jan 25, 2013 at 9:37 AM, SpinFlo  wrote:
> sorry for the quotes after message, this is automatic by gmail :S

And it's not 'automatic' by gmail, I use gmail, just click the
'in-line' button (3 dots).

On Fri, Jan 25, 2013 at 11:07 AM, Xyne  wrote:
> /etc/makepkg.conf -> SRCDEST
>
> Set that to the directory of your choice and all source files should be saved
> there. Common sources will be automatically detected.
>
> (yeah, via symlinks... but if this is the approach that you meant, it wasn't
> clear)

Yes SRCDEST is better but won't help for yaourt users. I can't
remember when/why I started making my own symlinks, perhaps to prevent
one directory being way too full (harder to spring clean). In any
case, my apologies, SRCDEST is obviously the better solution here.

Re: [aur-general] NVIDIA drivers

[Oon-Ee Ng]

On Fri, Jan 25, 2013 at 9:19 AM, SpinFlo  wrote:
> well, i ve upload this package for the reason explain by @alucryd,
> need download up to 4 times the nvidia blob drivers for install
> dkms-nvidia-beta (was mine and left to use this package),
> nvidia-utils-beta, lib32-nvidia-utils-beta and lib32-libcl.

Bottom-post please, like this.

And why will symlinks not work for your purpose? Or is the purpose to
be able to use yaourt or another AUR helper?

Re: [aur-general] NVIDIA drivers

[Oon-Ee Ng]

On Fri, Jan 25, 2013 at 6:34 AM, Maxime Gauduin  wrote:
> That means downloading the x86_64 blob 2 times and the
> i686 one 1 time (I'm using a dkms version to not download them one more
> time for each of my kernels).

Symlinks, man

I fail to see the benefit beyond download size (which symlinks solve).
AUR helpers do a fundamentally tough job and 'because its easier for
them' isn't really an argument I think, especially with the bash
hackery some PKGBUILDs use.

Re: [aur-general] Please delete glselect and pselect related packages

[Oon-Ee Ng]

On Sun, Dec 2, 2012 at 12:02 PM, Felix Yan  wrote:
> On 12/02/2012 07:16 AM, Oon-Ee Ng wrote:
>> Hi, [1] and [2] are old outdated and non-working packages. [3] was
>> someone's project but the github doesn't exist anymore.
>>
>> [1] - https://aur.archlinux.org/packages/nvidia-173xx-utils-glselect/
>> [2] - https://aur.archlinux.org/packages/nvidia-96xx-utils-glselect/
>> [3] - https://aur.archlinux.org/packages/pselect-git/
> All removed, thanks.
>
>> P.S. - with the new AUR, once I provide the links, do I still need to
>> name the packages? The names are right there...
> It's OK for me to provide just these links =)


Thanks Felix.

[aur-general] Please delete glselect and pselect related packages

[Oon-Ee Ng]

Hi, [1] and [2] are old outdated and non-working packages. [3] was
someone's project but the github doesn't exist anymore.

[1] - https://aur.archlinux.org/packages/nvidia-173xx-utils-glselect/
[2] - https://aur.archlinux.org/packages/nvidia-96xx-utils-glselect/
[3] - https://aur.archlinux.org/packages/pselect-git/


P.S. - with the new AUR, once I provide the links, do I still need to
name the packages? The names are right there...

Re: [aur-general] Systemd service files

[Oon-Ee Ng]

On 28 Nov 2012 05:13, "Martti Kühne"  wrote:
>
> On Tue, Nov 27, 2012 at 9:25 AM, Stefan J. Betz 
wrote:
> >
> > Never enable any service on install ;-)
> >
>
> +1
> Please keep arch passive.
> No automated configs, no automated breakage I'll have to search for.
> Thank you.
>
> Cheers
> mar77i

Yes, we should not have the privilege of breaking our systems taken away
from us.

Re: [aur-general] craftbukkit getting frequently flagged

[Oon-Ee Ng]

On Sat, Nov 3, 2012 at 3:12 PM, Schala Zeal wrote:
>
> On 11/02/2012 07:32 PM, Oon-Ee Ng wrote:
>
>> Just post a comment on the package? When this happens to my own packages I
>> end up just leaving it marked out of date to save myself the emails, then
>> tell people 'if its really out of date, post a comment'.
>>
>>  I did, but no one will note it.
>

Anyone who will not note it will just see that its already flagged out of
date and not bother.

Anyone who would bother beyond that (for example to post a comment to ask
for it to be updated) would read your comment.

Re: [aur-general] craftbukkit getting frequently flagged

[Oon-Ee Ng]

Just post a comment on the package? When this happens to my own packages I
end up just leaving it marked out of date to save myself the emails, then
tell people 'if its really out of date, post a comment'.


On Sat, Nov 3, 2012 at 9:44 AM, Schala Zeal wrote:

> I would appreciate it if those using craftbukkit would not flag it out of
> date over and over. 1.3.2r3.0 is the latest stable release. If you want the
> snapshot, please see 
> https://aur.archlinux.org/**packages.php?ID=62317
>
> 1.4.2r0.1 is an unstable release and does not constitute flagging
> craftbukkit out of date. Thanks.
>

Re: [aur-general] nvidia-ice needs to be updated

[Oon-Ee Ng]

Getting a bit off-topic here, but if it regularly needs patching take
a look at the example patch given with nvidia-beta-all (PKGBUILD
includes logic to include arbitrary patches if the names match from
the srcdir).

On Thu, Oct 25, 2012 at 9:24 PM, Cian Mc Govern  wrote:
> Didn't know it existed :) I've adapted the nvidia-all package:
> https://aur.archlinux.org/packages.php?ID=32908 and updated it for
> 304.60. I used your PKGBUILD from the nvidia-beta-all package but
> changed it slightly so that it doesn't build the module for the
> linux-mainline kernel. I'm currently maintaining the nvidia-mainline
> package and I think it's better to keep them seperate as the
> nvidia-mainline package regularly needs patching to compile against
> the mainline kernel.
>
> On 25 October 2012 01:38, Oon-Ee Ng  wrote:
>> Shameless plug - why not just use nvidia-all (or nvidia-beta-all if
>> that floats your boat). nvidea-X packages, where X is some custom
>> kernel, tend to have very low usage since usage of X kernel to begin
>> with is pretty low, and nvidia-X usage must be a subset of that.
>>
>> On Thu, Oct 25, 2012 at 5:03 AM, Cian Mc Govern  
>> wrote:
>>> No, I'll send the maintainer an email now. I didn't think there would
>>> be any need seeing as it hasn't been updated in over a year.
>>>
>>> On 24 October 2012 22:00, Alexandre Ferrando  wrote:
>>>> On 24 October 2012 22:47, Cian Mc Govern  wrote:
>>>>> The nvidia-ice package: https://aur.archlinux.org/packages.php?ID=15441 
>>>>> hasn't
>>>>> been updated in over a year. Can the powers at be transfer the maintenance
>>>>> of the package over to me? My username is cian1500ww.
>>>>>
>>>>> Thanks.
>>>>
>>>> Have you contacted the maintainer over e-mail and waited two weeks for
>>>> response? If yes, ask for orphaning the package. If not, contact him.
>>>>
>>>> Trusted Users can't just transfer maintenance of one package from one
>>>> person to another.
>
>
>
> --
> Cian Mc Govern
> Killaneen
> Ballinamore
> Co. Leitrim
> Ireland
> http://www.cianmcgovern.com
>
> My GPG Public Key: http://www.cianmcgovern.com/gpg-public-key/

Re: [aur-general] nvidia-ice needs to be updated

[Oon-Ee Ng]

Shameless plug - why not just use nvidia-all (or nvidia-beta-all if
that floats your boat). nvidea-X packages, where X is some custom
kernel, tend to have very low usage since usage of X kernel to begin
with is pretty low, and nvidia-X usage must be a subset of that.

On Thu, Oct 25, 2012 at 5:03 AM, Cian Mc Govern  wrote:
> No, I'll send the maintainer an email now. I didn't think there would
> be any need seeing as it hasn't been updated in over a year.
>
> On 24 October 2012 22:00, Alexandre Ferrando  wrote:
>> On 24 October 2012 22:47, Cian Mc Govern  wrote:
>>> The nvidia-ice package: https://aur.archlinux.org/packages.php?ID=15441 
>>> hasn't
>>> been updated in over a year. Can the powers at be transfer the maintenance
>>> of the package over to me? My username is cian1500ww.
>>>
>>> Thanks.
>>
>> Have you contacted the maintainer over e-mail and waited two weeks for
>> response? If yes, ask for orphaning the package. If not, contact him.
>>
>> Trusted Users can't just transfer maintenance of one package from one
>> person to another.

Re: [aur-general] python-foo and python2-foo - should they conflict?

[Oon-Ee Ng]

On Tue, Oct 16, 2012 at 5:02 PM, Felix Yan  wrote:
> As mentioned in the Arch Packaging Standards [1]:
> /usr/share/doc/{pkg}Application documentation
>
> You should rename the documentation folder of your packages to
> /usr/share/doc/$pkgname, so there would be not anymore conflict.
>
> [1] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards

The thing is both use /usr/share/doc/python-foo. Yeah I guess it makes
sense that one should use /usr/share/doc/python2-foo, thanks =)

[aur-general] python-foo and python2-foo - should they conflict?

[Oon-Ee Ng]

Was just trying out some python packages and I realized I can't have
both the python and python2 variants installed at the same time for
python-networkx.

Of course, there's conflicts with the license files and perhaps
documentation, but other than that I wonder whether there's a use-case
for having both installed (I'm in an academic setting, and I use both
python3 and python2).

Should I simply custom-PKGBUILD such issues or does it make sense to
have, for example:-
1. python-foo provides all files shared between python3 and python2 variants
2. python2-foo depends on python-foo
?

[aur-general] xmonad moved out of community-testing without its dependency haskell-extensible-exceptions

[Oon-Ee Ng]

Just though I'd bring it to the TU's attention -
https://bbs.archlinux.org/viewtopic.php?id=150334

Re: [aur-general] Delete request

[Oon-Ee Ng]

On Oct 7, 2012 6:03 PM, "Miguel A. M."  wrote:
>
> Hi!
>
> These packages are discontinued, please delete:
>
>
> https://aur.archlinux.org/packages.php?ID=49488
> https://aur.archlinux.org/packages.php?ID=50619
> https://aur.archlinux.org/packages.php?ID=50621
> https://aur.archlinux.org/packages.php?ID=50622
> https://aur.archlinux.org/packages.php?ID=50623
> https://aur.archlinux.org/packages.php?ID=50624
> https://aur.archlinux.org/packages.php?ID=50130
> https://aur.archlinux.org/packages.php?ID=49691
>
> Thanks!
Should package names be included?

[aur-general] Multiple Kernel modules in the AUR [WAS: Disown request: nvidia-pae]

[Oon-Ee Ng]

On Tue, Sep 18, 2012 at 3:47 AM, Dave Reisner  wrote:
> On Mon, Sep 17, 2012 at 09:38:30PM +0200, Robert Knauer wrote:
>> Hello,
>> please disown nvidia-pae[1], it's outdated for more than a month now
>> and I mailed the maintainer on 1st of September and got no answer.
>>
>> Thanks,
>> Robert
>>
>> [1] https://aur.archlinux.org/packages.php?ID=40101
>
> Don't take this personally... you're just the one who happened to bring
> it up. Do we _really_ need all this duplication? Does every kernel in
> the AUR needs its own _from_ _source_ instructions to build kernel
> modules? Really, these should all be about 3-4 lines to change in the
> extra/nvidia PKGBUILD. Instead, we have...
>
> nvidia-apparmor
> nvidia-bede
> nvidia-bfs
> nvidia-bl
> nvidia-ck
> nvidia-custom
> nvidia-fbcondecor
> nvidia-ice
> nvidia-ll
> nvidia-lqx
> nvidia-mainline
> nvidia-pae
> nvidia-pf
> nvidia-rifs
> nvidia-rt
> nvidia-uksm
> nvidia-zen
>
> I'm sure these are all unique and beautiful in their own way, but
> really, they're all duplicates as far as I'm concerned. nvidia is the
> biggest offender of this, but it certainly applies to other modules as
> well.
>
> 
>
> dave

Firstly - full disclosure - I'm the author and maintainer of the
hackish nvidia-beta-all package (someone else based nvidia-all from
that). It basically builds the nvidia module for every exiting kernel
(including specific patches if needed).

When initially submitting the package there was some discussion about
whether such a PKGBUILD which is non-reproducable (would produce
different results on different machines) violates the AUR's
guidelines. The only alternative to that (if reproducability is
important) would be the various nvidia packages as we currently have.

Of course, I never really agreed with that line of reasoning simply
because as it is compiling any random package on two different
machines could produce different results due to autotools or similar.

Re: [aur-general] Orphan request

[Oon-Ee Ng]

On Wed, Jul 11, 2012 at 9:00 AM, Hugo Osvaldo Barrera
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> opensmtpd [1] seems to be abandoned.  I marked it out of date, and
> left the author some tips on how to improve the PKGBUILD over a month
> ago, and there hasn't been any activity since.
>
> I was wondering if this could be orphaned so I can adopt it and
> maintain it myself.
>
> Thanks,
>
> [1] https://aur.archlinux.org/packages.php?ID=50709

Have you sent him an email?

Re: [aur-general] [arch-general] [arch-dev-public] final leg of /lib removal

[Oon-Ee Ng]

On Jul 4, 2012 3:38 AM, "Tom Gundersen"  wrote:

> We all know that no one reads the news items, nor dev-public, so I
> think adding an extra warning should save us a few hundred
> mails/forumposts/IRC conversations.
>
> -t

I see a good opportunity to start pruning the list of users of all the
above channels =). The same users who don't read the above may not notice
post-upgrade messages either.

On the flip side, most custom kernel users should be more savvy than the
average, do I don't see much of a problem. I maintain two aur kennels,
shall I implement the move now (seems like it'd work even before kmod
upgrades)?

Re: [aur-general] testificate user massive spamming

[Oon-Ee Ng]

2012/6/20 Callan Barrett :
> Hey guys posting +1 can you please quit it. The irony is making my head 
> explode.
>
+1 =p

[aur-general] Please delete dovecot-systemd

[Oon-Ee Ng]

Please delete dovecot-systemd [1], I am the maintainer.

Reason: systemd support already to dovecot in [extra] (bug-report
closed here [2])

[1] - https://aur.archlinux.org/packages.php?ID=47523
[2] - https://bugs.archlinux.org/task/22601

Re: [aur-general] Idea for AUR improvement

[Oon-Ee Ng]

On Jun 1, 2012 10:03 PM, "Marcin 'sirmacik' Karpezo" <
mar...@karpezo.pl> wrote:
>
> Hi there!
>
> Few days ago I’ve installed Archlinux on my laptop again. One of the
> first changes I’ve noticed in my *.archlinux.org accounts was loosing
> all packages I was maintaining in AUR.
>
> It’s completely understandable because I was the one to say in one of
> my comments that I hope to never use Arch again… but here I am having
> Arch on the second partition, next to Gentoo.
>
> The idea is to add some tracking of AUR package maintainers (I’m not
> sure if there isn’t some system like this first part already). If they
> have more than some number of packages out of date and they haven’t
> been logged in some time lets orphan their packages. This is how it is
> working now but manually.
>
> The next step is retrieval. If our maintainer logged in again and he’s
> pushing some new packages to AUR lets bring him his packages. But not
> all, only those which are still orphaned.
>
> Such automation will be IMO a big improvement to the whole system. Just
> an idea, but if anyone is interested in implementing it I’ll be glad to
> help.
>
> --
> Regards
> Marcin 'sirmacik' Karpezo
> http://sirmacik.net

Somehow I don't see the "stopped using arch for a long while and now coming
back and wanting his packages back" demographic to be significantly
large...

Re: [aur-general] Catalyst/Nvidia cleanup

[Oon-Ee Ng]

Sorry for top posting, android phone has a word limit for editing in
line...

As author of the (hacky) nvidia-*-all package, I can safely say that
they're not meant to replace individual nvidia-*. Unnecessary rebuilding
when only one kernel is updated and just not being the most kiss solution
for a single custom kernel are the reasons.

However, I do know that most of the nvidia-* packages are unmaintained, so
it's up to the tus I guess.
On May 12, 2012 3:32 AM, "Jesse Juhani Jaara"  wrote:

Re: [aur-general] Vote results for speps' TU application

[Oon-Ee Ng]

On Wed, May 9, 2012 at 7:20 AM, speps  wrote:
> On Tue, 8 May 2012 21:26:40 +0200
> Thorsten Töpper  wrote:
>
>> Hello,
>>
>> the vote for speps' application is over so it's time to publish the
>> results:
>>
>>
>> Yes:           20
>> No:             1
>> Abstain:        2
>> Participants:  23
>> active TUs:    27
>>
>> So the conditions are met, congratulations speps, please follow the
>> further procedure as described in the wiki[1]. :-)
>>
>> I've already updated your status at the AUR.
>>
>> Thorsten
>>
>> [1] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
>>
>> --
>> Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/
>> Key: 295AFBF4     FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
>
> Oh yeah :)
> Thank you all guys for your kind words and support.
>
> It's time to complete my initiation and to start contributing as a TU now ;)
>
>
> - speps -

And, of course, check out the TU tower where the goodies are stored =p

Re: [aur-general] TU application - speps

[Oon-Ee Ng]

On Fri, Apr 27, 2012 at 3:34 PM, Massimiliano Torromeo
 wrote:
> I never had a problem revealing my real-life identity on the internet
> but I also don't think that it actually changes anything since, as
> everyone else already pointed out, I think GPG identities are already
> providing the necessary security requirements for Arch.
> Even if I met speps in the flesh, it's not like I would trust him any
> more than I do now just because he has a face.

I've been trying VERY HARD not to jump in with off-topic comments at
various points in this thread, but couldn't resist just this one
time...

*ahem*

That depends on the face, doesn't it?

*gets his coat*

Re: [aur-general] Compiz* package cleanup

[Oon-Ee Ng]

On Tue, Apr 10, 2012 at 11:41 AM, Hugo Osvaldo Barrera
 wrote:
> The following packages should be deleted (or merged in some cases).

It's great that you're clearing thing up, good job =). You really
should include package names in the email as well for posterity's sake
(once the TU deletes the referred to packages, the links go nowhere so
noone will know the exact names of the deleted packages.

Re: [aur-general] Automated Package Removal

[Oon-Ee Ng]

On Mon, Apr 9, 2012 at 4:28 PM, Allan McRae  wrote:
> On 09/04/12 17:56, Daniel Campbell wrote:
>> I would contribute if a. My dev machine had internet and b. If i thought my 
>> work had a chance of being considered. Given that I'm not a TU or a regular 
>> among the devs, my work would not likely be accepted.
>
> What a load of crap...  Everyone submitted their first patch at one stage.
>
I'd be interested to know WHY you think your work has no chance of
being considered. Just look at the recent history of netcfg, as long
as someone's working on it there's no bureaucracy or any such crap.

Re: [aur-general] Removal request: google-chrome-mini

[Oon-Ee Ng]

On Mon, Mar 26, 2012 at 3:18 PM, Daniel Wallace
 wrote:
> this is the email I just got
> On Sun, Mar 25, 2012 at 10:55:16PM -0700, Tai-Lin Chu wrote:
>>    i really dont think removing a pkgbuild just because they are
>>    similar is a
>>    good idea, given that we have tons of similar PKGBUILD.
>>    if we do this, please do the same thing for these families:
>>    1. chromium
>>    2. vlc
>>    3. mplayer
>>    4. ...
>>    you will see that aur is supposed to be free. anyone should be
>>    able to
>>    upload pkgbuild.

I know I have no standing in AUR decision-making, but I find the
uploader's 'logic' un-understandable. If his package is not necessary
and changes nothing besides adding a dependency which already has
'provides=', how can he compare it with compile-flag-varying packages?

Re: [aur-general] Removal request: google-chrome-mini

[Oon-Ee Ng]

On Mon, Mar 26, 2012 at 12:14 PM, Taylor Lookabaugh
 wrote:
> Have you tried emailing him personally?

Obviously, from the reply seen earlier in the thread.

Re: [aur-general] Deletion Request

[Oon-Ee Ng]

On Mon, Mar 26, 2012 at 7:31 AM, Seblu  wrote:
> On Mon, Mar 26, 2012 at 1:25 AM, BxS  wrote:
>> Dear TUs,
>>
>> please delete package [1], it as been replaced by package [2].
>>
>> [1] https://aur.archlinux.org/packages.php?ID=57910
>> [2] https://aur.archlinux.org/packages.php?ID=57960
>> Thanks.
>>
> Done. Thanks.
>
Shouldn't the package names have been mentioned somewhere as well?

Re: [aur-general] Removal request: google-chrome-mini

[Oon-Ee Ng]

On Mar 16, 2012 8:49 PM, "Det"  wrote:
>
> This is not even funny: https://aur.archlinux.org/packages.php?ID=57611
> - A clone of 'google-chrome-dev'
> - Otherwise the same but the build and dependencies somehow more 'minimal'
> - In practice completely useless
>
>  Det

Package is the author's idea of KISS, saw a thread to that effect in the
forums.

Re: [aur-general] AUR helpers and AUR standards

[Oon-Ee Ng]

On Fri, Mar 2, 2012 at 8:33 AM, Heiko Baums  wrote:
> Am Fri, 2 Mar 2012 07:45:34 +0800
> schrieb Oon-Ee Ng :
>
>> Splitting off from the TU application thread that's becoming more of a
>> discussion on the above:-
>>
>> My (user) perspective - when did being able/not to install packages
>> from a helper (for example yaourt) become a benchmark for deciding how
>> 'correct' a PKGBUILD is?
>
> It's not only the helper, but it's one point. And it was not only the
> split package but also those two depends arrays in some PKGBUILDs.
>
> A correct PKGBUILD should in my opinion respect the official packaging
> standards. And since AUR doesn't support split packages it's just not
> officially supported.

As I understand it the reason the AUR doesn't support split packages
is more along the lines of "hard to implement" and/or "noone has
bothered to add it" rather than "the AUR shall not have split
packages". If a workaround allows split packages to work fine without
having to rewrite the AUR, that's a GOOD thing to me. Note: 'work'
means with makepkg.
>
> And why can't a package being built in a way that it can easily
> installed by those helpers?
>
Helpers are only helpers. Nothing wrong with using them, but they're:-
a) not official
b) not a suitable substitute for knowing how to download a tarball and
run makepkg

If a user can't do b) AUR helpers do them a dis-service, IMO. Better
to learn what's going on behind the scenes.

I've used yaourt and bauerbill before, and they DO make things easier,
but if we ever reach the point that a large group of users only know
how to use the AUR through helpers Arch would be a very different (and
worse) place.

[aur-general] AUR helpers and AUR standards

[Oon-Ee Ng]

Splitting off from the TU application thread that's becoming more of a
discussion on the above:-

My (user) perspective - when did being able/not to install packages
from a helper (for example yaourt) become a benchmark for deciding how
'correct' a PKGBUILD is?

Re: [aur-general] Disown Request cellwriter

[Oon-Ee Ng]

On Feb 28, 2012 9:39 PM, "Adonay Sanz Alsina"  wrote:
>
> It's flagged out-of-date cause not compile. I can mantain it.
>
Again, please don't do that, out-of-date doesn't mean "has a bug"

Re: [aur-general] removal request kde icon tasks

[Oon-Ee Ng]

On Fri, Jan 27, 2012 at 6:43 PM, Alexander Rødseth  wrote:
> Hi,
>
> If a dev/tu adds a package to one of the official repos, they are
> supposed to also remove the AUR packages for the same software, as
> part of the process.
>
Though I guess in this case this won't be done until it moves to [extra]?

Re: [aur-general] [Removal Request] r8169

[Oon-Ee Ng]

On Fri, Dec 9, 2011 at 9:05 AM, Jason St. John  wrote:
> I am requesting that AUR package r8169 (
> https://aur.archlinux.org/packages.php?ID=44317 ) be removed.
>
> The r8169 package seems to have been created because of a bug in the
> 2.6.36 kernel which has already been fixed, apparently. Note that the
> r8169 kernel module is already in the kernel (and has been for a
> while).
>
> The submitter of the package (darkmug) stated the following in the comments:
> "Kernel version has a bug on current arch version. The problem is
> described on https://bbs.archlinux.org/viewtopic.php?pid=761029
> This package has a patch that solves it. As soon as arch's version
> solves it, I pretend to remove from aur."
>
> Thanks

Well now that its ACTUALLY been removed there's no reason to pretend
to remove it =)

Re: [aur-general] Deletion request

[Oon-Ee Ng]

On Wed, Dec 7, 2011 at 1:13 PM, Xyne  wrote:
> rafael ff1 wrote:
>> lib32-gail has a broken URL, is not updated for long time (since
>> October 2008) and this software is implemented by Gnome's ATK since
>> version 3.0.
>>
>> https://aur.archlinux.org/packages.php?ID=17078
>>
>> Please delete.
>
>> lib32-libcurl3 URL is broken, orphan and not update since September 2008
>>
>> https://aur.archlinux.org/packages.php?ID=19376
>
>
> done & done
>
> When I delete packages that old, it feels like I'm vandalizing a museum.
>
> *coughs from the dust*
>
> /Xyne

Mummies will shortly emerge to punish you.

Re: [aur-general] GPG Key Signing

[Oon-Ee Ng]

On Dec 1, 2011 9:38 PM, "Jelle van der Waa"  wrote:
>
> On 01/12/11 14:27, Ángel Velásquez wrote:
> > 2011/12/1 Xyne :
> >> Hi Allan,
> >>
> >> I'm in the process of getting my key signed (Pierre has signed, Thomas
and
> >> Ionut should sign soon, not sure if Dan will sign due to not knowing
my real
> >> name).
> >
> > I can't understand yet your drama giving your name.
> >
> > Seriously, grow up.
> >
> >
> >
> >
> How rude!
>
> Well actually I would like to know your name too, I don't see any reason
> why wouldn't give it.
>
> --
> Jelle van der Waa

I remember reading something about knowing a person's "true name" giving
you complete power over someone...

[aur-general] Please remove emesene2

[Oon-Ee Ng]

Hi, emesene2[1] is in [community] and should be deleted.

1 - https://aur.archlinux.org/packages.php?ID=48535

Re: [aur-general] Please delete pidgin-gtalk-shared-status

[Oon-Ee Ng]

On Mon, Oct 17, 2011 at 3:42 PM, Evangelos Foutras
 wrote:
> On Mon, Oct 17, 2011 at 9:23 AM, Oon-Ee Ng  wrote:
>> pidgin-gtalk-shared-status[1] should be deleted, as
>> pidgin-gtalksharedstatus [2] is a better (my subjective opinion) name
>> and pre-dates it, plus has more votes (and is actually up-to-date).
>
> Done.
>
>> I just disowned [2] myself since I don't use it anymore, but found [1]
>> while searching for it, so I thought keeping things clean is better
>> =).
>
> You're still listed as the maintainer for it. Maybe you forgot to disown it? 
> :p
>
Gracias, yes I did forget =)

[aur-general] Please delete pidgin-gtalk-shared-status

[Oon-Ee Ng]

pidgin-gtalk-shared-status[1] should be deleted, as
pidgin-gtalksharedstatus [2] is a better (my subjective opinion) name
and pre-dates it, plus has more votes (and is actually up-to-date).

I just disowned [2] myself since I don't use it anymore, but found [1]
while searching for it, so I thought keeping things clean is better
=).

[1] - https://aur.archlinux.org/packages.php?ID=48997
[2] - https://aur.archlinux.org/packages.php?ID=38551

[aur-general] Please delete conky-lua-nv-old

[Oon-Ee Ng]

conky-lua-nv-old [1] is an exact duplicate (deleting two commented
lines) of conky-lua-nv [2]. The latter is out-of-date, but has more
votes and predates (and was updated more recently) than the former.
Please delete [1].

[1] - https://aur.archlinux.org/packages.php?ID=47051
[2] - https://aur.archlinux.org/packages.php?ID=36405

Re: [aur-general] VCS Packages

[Oon-Ee Ng]

On Sep 10, 2011 9:09 AM, "Stefan Husmann" 
wrote:
>
> Am 09.09.2011 14:45, schrieb Thomas Dziedzic:
>
>> On Fri, Sep 9, 2011 at 5:38 AM, gadget3000  wrote:
>>
>>> *Repo has moved:*
>>> audacious-hg (https://aur.archlinux.org/packages.php?ID=25204) now uses
>>> git
>>> and has been replaced by audacious-git (
>>> https://aur.archlinux.org/packages.php?ID=49520)
>>> audacious-plugins-hg (https://aur.archlinux.org/packages.php?ID=11672)
now
>>> uses git and has been replaced by audacious-plugins-git (
>>> https://aur.archlinux.org/packages.php?ID=49521)
>>> comedilib-cvs (https://aur.archlinux.org/packages.php?ID=22187) now uses
>>> git
>>> and has been replaced by comedilib-git (
>>> https://aur.archlinux.org/packages.php?ID=50864)
>>> dolphin-emu-svn (https://aur.archlinux.org/packages.php?ID=21990) now
uses
>>> git and has been replaced by dolphin-emu-git (
>>> https://aur.archlinux.org/packages.php?ID=51679)
>>>
>>> *Other Considerations:*
>>> emacs-git (https://aur.archlinux.org/packages.php?ID=48701) officially
>>> uses
>>> bzr. emacs-bzr exists (https://aur.archlinux.org/packages.php?ID=7).
>>>
>>> *(Just for reference). Repo has moved. Needs a replacement package
before
>>> merging/deletion:*
>>> All mcabber-module-*-git packages have moved to mercurial. Some may also
be
>>> built into mcabber-hg now as well.
>>> python-commons-git (https://aur.archlinux.org/packages.php?ID=47324) now
>>> uses svn.
>>> thrift-git (https://aur.archlinux.org/packages.php?ID=17977) now uses
svn.
>>> phinix-git (https://aur.archlinux.org/packages.php?ID=48443). Dead repo.
I
>>> can't find a mirror but the repo died only between April and September
so
>>> another may pop up soon.
>>>
>>>
>>> Gadget3000
>>>
>>
>> All removed. Thanks!
>>
>> I didn't delete emacs-git because I don't know which one is official.
>> Upstream provides both git [1] and bzr [2] repos for emacs.
>>
>> [1] - http://savannah.gnu.org/git/?group=emacs
>> [2] - http://savannah.gnu.org/bzr/?group=emacs
>>
> bzr is the official VCS for emacs. The git repo is always a few days
behind.
>
> deleted emacs-git.

Not that I'm in any way affected, but as long as both bzr and git repos work
what's the harm in leaving them there? Some might prefer one or the other
(like, I may already have git installed but not bzr). Just something that
came to mind.

Re: [aur-general] Please remove 100% duplicate

[Oon-Ee Ng]

On Fri, Aug 26, 2011 at 6:29 AM, Andrea Scarpino  wrote:
> On 26 August 2011 00:17, Dan Vratil  wrote:
>> On Friday, August 26, 2011 01:00:51 Jesse Jaara wrote:
>>> So someone uploaded a copy of my PKGBUILD
>>> for [1]libpng12 with the only changes being
>>> a name change (to get it into AUR) and
>>> marked himself as maintainer and made me
>>> a contributor. Then he tells people to
>>> try his 100% copy PKGBUILD on the comments
>>> O_o. Please kill [2]libpng12-working
>>>
>>> [1]: https://aur.archlinux.org/packages.php?ID=33795
>>> [2]: https://aur.archlinux.org/packages.php?ID=51855
>>
>>
>> I believe the other package of his is the same case. He uploaded google-
>> musicmanager-current [1] as a duplicate of google-musicmanager [2], only 
>> fixed
>> md5 sums. Also the versioning is incorrect.
> Thanks. Both removed.
>
Sorry to butt in, but should the user be informed to at least read the
AUR wiki page? I immediately thought of doing that, but since the
packages are deleted...

Re: [aur-general] Package merge request: kernel26/linux-ice and kernel26/linux-rt-ice

[Oon-Ee Ng]

On Mon, Aug 22, 2011 at 1:43 PM, Evangelos Foutras
 wrote:
> On Mon, Aug 22, 2011 at 8:10 AM, Oon-Ee Ng  wrote:
>> Hi, please remove kernel26-ice [1] and merge comments/votes with linux-ice 
>> [2].
>>
>> Also, I would prefer that kernel26-rt-ice [3] be removed and
>> comments/votes merged with linux-rt-ice [4].
>
> Both done.
>
Thanks much

[aur-general] Package merge request: kernel26/linux-ice and kernel26/linux-rt-ice

[Oon-Ee Ng]

Hi, please remove kernel26-ice [1] and merge comments/votes with linux-ice [2].

Also, I would prefer that kernel26-rt-ice [3] be removed and
comments/votes merged with linux-rt-ice [4]. The slight problem with
that is that nvidia proprietary driver users will not be able to use
linux-rt-ice, since the latest editions of the -rt patchset export
several symbols as GPL which disallow compilation of the nvidia
driver. Re-exporting (or modifying the nvidia license) with a patch is
simple but not permitted under the terms of the GPL (as I understand
it). In any case, this will not be resolved by the passage of time, so
users will just have to use nouveau or patch themselves.

[1] - http://aur.archlinux.org/packages.php?ID=15224
[2] - http://aur.archlinux.org/packages.php?ID=51077
[3] - http://aur.archlinux.org/packages.php?ID=31893
[4] - http://aur.archlinux.org/packages.php?ID=51166

Re: [aur-general] OK! changing a PKG's name and retaining votes/comments

[Oon-Ee Ng]

On Aug 21, 2011 3:38 AM, "Ray Rashif"  wrote:
>
> On 11 August 2011 22:25, Lukas Fleischer  wrote:
> > On Sun, Jul 31, 2011 at 07:09:44PM +0200, Lukas Fleischer wrote:
> >> On Fri, Jul 22, 2011 at 05:35:00PM +0200, Lukas Fleischer wrote:
> >> > On Fri, Jul 22, 2011 at 10:52:54AM -0400, member graysky wrote:
> >> > > Crap... I thought it was a done deal :(
> >> >
> >> > This is still on my TODO list. I'll probably implement this once my
> >> > development box is up again (it died some days ago). Further details
> >> > should be discussed on aur-dev, please.
> >>
> >> Just sent a patch set to aur-dev [1], [2], [3].
> >
> > Pushed to master [1], [2].
>
> ...aand it works great!
>
> So guys, spread the word, the feature is there, so if your package
> needs a rename, please mention it so the TU merges the packages

So could I request deletion of a new package (linux-x for example) and
renaming of kernel26-x to linux-x?

Re: [aur-general] Deletion Request

[Oon-Ee Ng]

On Thu, Aug 4, 2011 at 12:58 AM, rafael ff1  wrote:
> lib32-gmp-dev [1] is outdated for a thousand years and the maintainer seems
> to have forgotten this poor. Also, this resource is already provided by
> another package (lib32-gmp4).
>
> [1] https://aur.archlinux.org/packages.php?ID=28554
>
> Please delete lib32-gmp-dev.
>
> Thanks,
>
> -- Rafael
>
A thousand? Yet another reason Arch is the best, we pre-date computers
(and electricity, for that matter).

Re: [aur-general] Deletion request

[Oon-Ee Ng]

On Tue, Jul 26, 2011 at 2:45 AM, Alessio Sergi  wrote:
> Hi TUs,
> please delete the following packages:
>
> ccsm++ [1] replaced by ccsm-git [2];
> compiz-core++ [3] replaced by compiz-core-git [4];
> compiz-plugins-extra++ [5] replaced by compiz-plugins-extra-git [6];
> compiz-plugins-main++ [7] replaced by compiz-plugins-main-git [8];
> compizconfig-python++ [9] replaced by compizconfig-python-git [10];
> libcompizconfig++ [11] replaced by libcompizconfig-git [12];
> emerald++ [13] 'cause the right package is emerald-git [14].
>
> Also, please delete:
> compiz-git [15] and compiz-kde-git [16], both obsolete and superseded by
> compiz-core-git [4];
> compiz-bcop-git [17], obsolete; it doesn't exist anymore in new compiz 0.9.x
> [18];
> compiz-fusion-plugins-extra-git [19] and compiz-fusion-plugins-main-git
> [20], both obsolete and anyway superseded by
> compiz-plugins-{extra,main}-git [6][8].
>
> About the other compiz-fusion-plugin{s}-* packages [21-27], they should all
> be deleted 'cause they're out-of-date, broken (sources moved to [28]) and
> the right  pkgname schema should be compiz-plugin-*.
>
> Thanks in advance.
>
>  [1] http://aur.archlinux.org/packages.php?ID=35685
>  [2] http://aur.archlinux.org/packages.php?ID=11536
>  [3] http://aur.archlinux.org/packages.php?ID=35680
>  [4] http://aur.archlinux.org/packages.php?ID=26334
>  [5] http://aur.archlinux.org/packages.php?ID=35911
>  [6] http://aur.archlinux.org/packages.php?ID=50552
>  [7] http://aur.archlinux.org/packages.php?ID=35910
>  [8] http://aur.archlinux.org/packages.php?ID=50551
>  [9] http://aur.archlinux.org/packages.php?ID=35684
> [10] http://aur.archlinux.org/packages.php?ID=11730
> [11] http://aur.archlinux.org/packages.php?ID=35683
> [12] http://aur.archlinux.org/packages.php?ID=11734
>  [13] http://aur.archlinux.org/packages.php?ID=35959
> [14] http://aur.archlinux.org/packages.php?ID=11539
> [15] http://aur.archlinux.org/packages.php?ID=5904
> [16] http://aur.archlinux.org/packages.php?ID=12558
> [17] http://aur.archlinux.org/packages.php?ID=11731
> [18] http://releases.compiz-fusion.org/0.9.0/
> [19] http://aur.archlinux.org/packages.php?ID=11733
> [20] http://aur.archlinux.org/packages.php?ID=11732
> [21] https://aur.archlinux.org/packages.php?ID=24037
> [22] https://aur.archlinux.org/packages.php?ID=24027
> [23] https://aur.archlinux.org/packages.php?ID=18512
> [24] https://aur.archlinux.org/packages.php?ID=18394
> [25] https://aur.archlinux.org/packages.php?ID=38216
> [26] https://aur.archlinux.org/packages.php?ID=29209
> [27] https://aur.archlinux.org/packages.php?ID=14255
> [28] http://git.compiz.org/
>
> --
> Alessio Sergi
>

I can confirm for https://aur.archlinux.org/packages.php?ID=29209
(number 26 above), the greenscreen plugin should be deleted. I am the
maintainer.

[aur-general] Please delete mplayer-vdpau-pulse and mplayer-vdpau-pulse-svn

[Oon-Ee Ng]

Please delete mplayer-vdpau-pulse [1] and mplayer-vdpau-pulse-svn [2],
mplayer from the repos already has pulse support. I believe it has
vdpau support as well (mine does, here) but based on a quick browse at
the deps couldn't confirm that.

[1] - http://aur.archlinux.org/packages.php?ID=40575
[2] - http://aur.archlinux.org/packages.php?ID=36890

Re: [aur-general] removal of pidgin-gtalkinvisible

[Oon-Ee Ng]

On Fri, Jun 17, 2011 at 10:49 PM, Ray Rashif  wrote:
> On 17 June 2011 20:56, Martti Kühne  wrote:
>> On Fri, Jun 17, 2011 at 9:00 AM, Oon-Ee Ng  wrote:
>> 
>>> Actually, after some consideration his naming is more appropriate,
>>> since that's the name of the source tarball is gtalk-shared-status. I
>>> would like my package renamed to that name, though I would not object
>>> to deleting my package and leaving his one, as long as he can maintain
>>> it.
>>>
>>
>> Ng, I'm not actually using the package. If you are, it's a much better
>> deal if you maintain it, unless you're too busy with the rest of the
>> universe.
>
> That's great. You can disown for Ng to pick it up. When that happens,
> let us know and we'll remove the other package.
>
>
Yes I do use it, please disown.

Re: [aur-general] removal of pidgin-gtalkinvisible

[Oon-Ee Ng]

On Fri, Jun 17, 2011 at 2:17 PM, Ray Rashif  wrote:
> On 17 June 2011 10:34, Thomas Dziedzic  wrote:
>> On Thu, Jun 16, 2011 at 7:45 PM, Martti Kühne  wrote:
>>
>>> please delete pidgin-gtalkinvisible [1], I'm the maintainer and
>>> announced deprecation in favor of pidgin-gtalk-shared-status [2] a
>>> month ago.
>>>
>>> cheers! mar77i
>>>
>>> [1] https://aur.archlinux.org/packages.php?ID=30136
>>> [2] https://aur.archlinux.org/packages.php?ID=48997
>>>
>>
>> terminated
>
> Hey Martti and everyone
>
> We see that Ng had uploaded the same thing before:
> http://aur.archlinux.org/packages.php?ID=38551
> And this is Martti's new upload: 
> http://aur.archlinux.org/packages.php?ID=48997
>
> 1. pidgin-gtalksharedstatus
> 2. pidgin-gtalk-shared-status
>
> Usually the new one would not be honoured, but Ng, do you think you
> would want to rename your package? I think a better name is following
> the $client-$protocol-$addon format which neither does, i.e
> 'pidgin-gtalk-sharedstatus'.
>
> Otherwise, if the name is not important, we'll have to remove Martti's
> version of the package.
>
Actually, after some consideration his naming is more appropriate,
since that's the name of the source tarball is gtalk-shared-status. I
would like my package renamed to that name, though I would not object
to deleting my package and leaving his one, as long as he can maintain
it.

Re: [aur-general] removal of pidgin-gtalkinvisible

[Oon-Ee Ng]

On Fri, Jun 17, 2011 at 8:45 AM, Martti Kühne  wrote:
> please delete pidgin-gtalkinvisible [1], I'm the maintainer and
> announced deprecation in favor of pidgin-gtalk-shared-status [2] a
> month ago.
>
> cheers! mar77i
>
> [1] https://aur.archlinux.org/packages.php?ID=30136
> [2] https://aur.archlinux.org/packages.php?ID=48997
>
I'm surprised to see package [2] above, did you not realize that
pidgin-gtalksharedstatus was already on the AUR[3] (uploaded by
myself)?

[3] - https://aur.archlinux.org/packages.php?ID=38551

Re: [aur-general] GDeskCal

[Oon-Ee Ng]

On Tue, May 24, 2011 at 8:00 PM, Martti Kühne  wrote:
> On Tue, May 24, 2011 at 12:39 PM, pauline martin <321enil...@gmail.com> wrote:
>> I don't know if this project has been discontinued or not, but it is flagged
>> as out of date and I have spent a good amount of time trying to find
>> somewhere to download the most recent release.  I was not able to find a
>> link anwhere to download the source from the website:
>> http://customize.org/gDeskCal .  If I could be pointed in the right
>> direction for the source code of this project if it is still alive that
>> would be wonderful.  It looks like a wonderful application and at least two
>> other packages in the AUR depend upon it so I would love to get it updated
>> or if it is a dead project to get it removed from the AUR.  The package is
>> in the AUR as gdeskcal and the two packages that I found that depend on it
>> are: gdeskcal-skins and gdeskcal-skin-simple.  Of the three only one is
>> being currently maintained.  I would be willing to maintain the other two if
>> they are not a dead project.  That one maintained project is using sources
>> from a different site than the main project is hosted on.  The maintainer is
>> Syntheed.  If I am reading the source right his sources are from freebsd, so
>> it is not of any help locating the original program if it is still in
>> development.
>>
>> Sincerely,
>> Pauline123
>
>
> hello
>
> There is a source package from fedora [1], also I was able to find the
> author's blog [2]. However there seems to be no more reference from
> the author to the project in question, so I'm positive the project is
> dead. Now with the upcoming deprecation of python2, I'm not sure if it
> makes any sense to keep the project either way. Also I have not come
> accross a replacement for it, either, and I'm not really sure what
> functionality is expected, except for it being a purely visual toy.
> However I have upgraded the package to fit current packaging standards
> and to use the fedora source for now.
>
> regards
> mar77i
>
> [1] 
> http://rpm.pbone.net/index.php3/stat/3/srodzaj/2/search/gdeskcal-1.01-2.fc10.src.rpm
> [2] http://pycage.blogspot.com/
>

There's always rainlendar

Re: [aur-general] Deletion request

[Oon-Ee Ng]

On Tue, May 24, 2011 at 2:04 AM, Thomas Dziedzic  wrote:
> On Mon, May 23, 2011 at 11:40 AM, roland karim  wrote:
>> I would suggest to delete the crossover-games-unsupported package, because 
>> there is no crossover beta package at the moment.
>>
>> Roland
>>
>>
>>
>
> target destroyed, thanks
>
> p.s. next time post a link to the package
>
Just to butt in a bit, isn't it a policy that *-beta and related
packages are simply left idle till the next *-beta (or in this case
*-unsupported) is released? Or has crossover froze their development?

[aur-general] Please delete kdelibs-nohal

[Oon-Ee Ng]

http://aur.archlinux.org/packages.php?ID=39002

kdelibs from [extra] no longer depends on hal, so this package is
outdated, orphaned, and no longer needed.

[aur-general] Please delete cairo-tee and cairo-xcb-tee

[Oon-Ee Ng]

cairo in [extra] already has tee support.

cairo-tee[1] and cairo-xcb-tee[2] can be deleted. Maintainer for [2]
has said as much, and [1] has no maintainer since the previous
maintainer disowned it once [extra] got cairo with --enable-tee.

[1] http://aur.archlinux.org/packages.php?ID=45693 is cairo-tee
[2] http://aur.archlinux.org/packages.php?ID=45772 is cairo-xcb-tee

Re: [aur-general] Orphan Request

[Oon-Ee Ng]

On Wed, Apr 13, 2011 at 7:53 PM, Mark Foxwell
 wrote:
> Hi,
>
> Please can you orphan offlineimap-git:
>
> https://aur.archlinux.org/packages.php?ID=24202
>
> I suggested changes to the PKGBUILD (see comments) and contacted the 
> maintainer directly by email but no reply in two weeks.
>
> Thanks,
>
> Mark (fastfret79)
>
Would be grateful if that was updated =). The offlineimap developments
currently in git are really interesting.

Re: [aur-general] Effective acne skin care

[Oon-Ee Ng]

On Sun, Apr 10, 2011 at 8:53 PM, Jelle van der Waa  wrote:
> On Sun, 2011-04-10 at 15:39 +0300, Bergen .. wrote:
>>
>
> Oh this is very usefull , is there some 3rd party repo providing this
> package?
> --
> Jelle van der Waa

Oh, are we feeding trolls now? =)

[aur-general] Web-client for emails: [WAS:Reflector]

[Oon-Ee Ng]

Re-subject - this is going OT.

On Tue, Apr 5, 2011 at 5:52 PM, Peter Lewis  wrote:
> On Mon, 04 Apr 2011, Oon-Ee Ng wrote:
>> I'll correct myself then, gmail+pentadactyl does not like the
>> combination of mailing lists I'm on. Some of them are badly configured
>> (thankfully none of the Arch ones) and have to be used with
>> reply-to-all, hence sometimes I press the wrong button, not
>> remembering which list I'm on.
>>
>> When I was using Evolution it was easy, Ctrl-L (reply-to-list) did
>> everything for me, but with web gmail there's no such button and I
>> have to remember whether to reply/reply-all depending on the list.
>> I'll try not to make the mistake again =).
>
> Umm... then don't use it, then, in favour of a client that works?
>
> Seriously though, I've never used GMail, but I see so many people on various
> lists apologising for the way it handles email. Just don't do it, kids.
>
> 
>
Gmail's web interface has THE best approach to threading. Ever. If you
have any other suggestion (web client or linux desktop client) which
comes anywhere close please let me know. Evolution's threading just
doesn't cut it, thunderbird's new one is close, but thunderbird is
basically a mouse-only interface, the keyboard shortcuts are so
horrific (and muttator is an abortion of a project AFAICS).

I've spent quite some time exploring the options, and settled on this.
Ideas always welcome, of course.

Re: [aur-general] Reflector

[Oon-Ee Ng]

On Mon, Apr 4, 2011 at 11:24 PM, Wieland Hoffmann
 wrote:
> Oon-Ee Ng wrote:
>> On Mon, Apr 4, 2011 at 10:11 PM, Xyne  wrote:
>>> p.s. Please stop CC'ing me replies. It just sends duplicate messages to 
>>> other
>>> folders.
>>>
>> Sorry about that, gmail doesn't like MLs
>
> GMail actually does like mailing lists. Just do not use the "Reply to
> all" button.
>
> Wieland
>
I'll correct myself then, gmail+pentadactyl does not like the
combination of mailing lists I'm on. Some of them are badly configured
(thankfully none of the Arch ones) and have to be used with
reply-to-all, hence sometimes I press the wrong button, not
remembering which list I'm on.

When I was using Evolution it was easy, Ctrl-L (reply-to-list) did
everything for me, but with web gmail there's no such button and I
have to remember whether to reply/reply-all depending on the list.
I'll try not to make the mistake again =).

Re: [aur-general] Reflector

[Oon-Ee Ng]

On Mon, Apr 4, 2011 at 10:11 PM, Xyne  wrote:
> Oon-Ee Ng wrote:
>
>> >> Indirectly comparing your old project to excrement?
>> >
>> > Indirectly comparing it to a dead body. But hey, if you bury excrement in 
>> > your
>> > back yard, who am I to judge you? At least it's not as bad as what Kaiting 
>> > does
>> > in his back yard.
>> >
>> Ah. I seem to lack some cultural context here =)
>
> Indeed. We should start a poll:
>
> 1) What is your current geographical location?
> 2) What do people typically bury in their back yards?
> 3) Is it illegal?
>
>
>
> I'll go first:
> 1) Slobovia
> 2) bodies
> 3) depends on the bodies

I'll go next then:-
1) Malaysia
2) Urban houses typically renovate all the way to the limit, hence no
backyard in my house (or any of my neighbours). Those who do have such
typically bury manure or the like for fertilizer.
3) The law is a fluid thing out here. Can you afford to pay the
necessary people?
>
>
>
>
> p.s. Please stop CC'ing me replies. It just sends duplicate messages to other
> folders.
>
Sorry about that, gmail doesn't like MLs

Re: [aur-general] Reflector

[Oon-Ee Ng]

On Mon, Apr 4, 2011 at 8:55 PM, Xyne  wrote:
> Oon-Ee Ng wrote:
>
>> > Hi,
>> >
>> > I just wanted to let you know that I've moved the new Reflector to 
>> > [community].
>> > Given that it is a direct replacement for the old one, I didn't see any 
>> > reason
>> > to pass through the AUR voting stage.
>> >
>> > Oh, and I buried the old one out in the back near the shed. If anyone has 
>> > some
>> > seeds to plant, I suggest you take advantage of the fertile soil.
>> >
>> > Regards,
>> > Xyne
>> >
>>
>> Indirectly comparing your old project to excrement?
>
> Indirectly comparing it to a dead body. But hey, if you bury excrement in your
> back yard, who am I to judge you? At least it's not as bad as what Kaiting 
> does
> in his back yard.
>
Ah. I seem to lack some cultural context here =)

Re: [aur-general] Reflector

[Oon-Ee Ng]

On Mon, Apr 4, 2011 at 1:26 PM, Xyne  wrote:
> Hi,
>
> I just wanted to let you know that I've moved the new Reflector to 
> [community].
> Given that it is a direct replacement for the old one, I didn't see any reason
> to pass through the AUR voting stage.
>
> Oh, and I buried the old one out in the back near the shed. If anyone has some
> seeds to plant, I suggest you take advantage of the fertile soil.
>
> Regards,
> Xyne
>

Indirectly comparing your old project to excrement?

[aur-general] When should pkgrel be updated?

[Oon-Ee Ng]

I've seen (in the past) various packages on the AUR which jumped by 3
or 4 pkgrels in a very short period of time. Sometimes it happens like
this:-

1. Maintainer changes something and breaks the package with pkgrel=2
2. Bug reported on comments. Maintainer reverts change and makes pkgrel=3

It can also happen like this:-

1. Maintainer makes changes to pkgdesc or cleans up some of the
commands, depends, etc. sets pkgrel=2

For both of the cases above, is pkgrel updating really necessary? For
the second one, I think not, as changing documentation doesn't
(shouldn't) require recompilation of the package by its users.
Similarly if depends changes, users who already have the package
installed would already have the dep, so no reason for such users to
upgrade?

For the first case its a bit more tricky. My reasoning is that if the
PKGBUILD breaks and can't be built at all, the maintainer could simply
release with the same pkgrel. Noone would have been able to build
pkgrel=2 in that example anyway, so why jump to pkgrel=3?

The reason I bring this up is because there's no easy way (yet) to
diff what's changed between versions of the package, and hence when I
notice a pkgrel change I can't really check to see what has been
changed and whether its worth recompiling the package (for larger
packages like firefox4 this can be significant).

Comments appreciated.

Re: [aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?

[Oon-Ee Ng]

Thanks for your response Rémy,

On Fri, Apr 1, 2011 at 7:54 AM, Rémy Oudompheng
 wrote:
> My definition was not about interactivity but dynamic nature.
> nvidia-beta-all is dynamic in the sense that it *computes* local
> variables that influence the resulting package. A reproducible package
> does as much as it can to hardcode the parameters and options it uses
> so that each time it is compiled it must produce the same results
> (this is usually false, because sonames may change and installed
> package may influence configuration steps).
>
> In other words, I think PKGBUILDs that could be incorportaed in a
> binary repository as is should not be removed in favour of a PKGBUILD
> that cannot be used for a binary repository: nvidia-beta-all can't be
> used for a repository because it can produce totally different
> packages with the same name, version and pkgrel. It is however a
> convenient thing to have.

Fair enough.
>
> By the way, I think you should tweak your PKGBUILD so that it
> correctly sets its $depends array. I don't think nvidia packages
> really depend on their associated kernels (I mean you can remove the
> kernels without removing the modules) but it prevents it from being
> used as is by people who only have kernel26-lts, for example.
>
Change made, thanks. Original copied from nvidia-beta, I'll inform the
maintainer that that should be removed. Only seems obvious once
someone has pointed it out (to me) =)

Re: [aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?

[Oon-Ee Ng]

On Fri, Apr 1, 2011 at 1:39 AM, Rémy Oudompheng
 wrote:
> 2011/3/31 Det :
>> Not to keep bugging your mailboxes but I suppose the only real reasons
>> for keeping all those nvidia-specific-kernel packages in the AUR boils
>> down to these:
>>
>> 1) The user wants to install an Nvidia driver for a non-booted kernel,
>> yet he doesn't want to install the driver for any the other kernels
>> since the rest (or at least 1 of them) use Nouveau or similar.
>>
>> 2) The maintainer wants to show a link to his unofficial repository
>> containing a precompiled version of his package.
>>
>> If these are enough to keep all that nvidia* stuff in the AUR then I
>> don't mind. It'd just be nice, if somebody came up with a PKGBUILD
>> that would ask the user which of the installed kernels he wanted the
>> nvidia driver to be installed to. In addition the package could hold a
>> simple text file listing all the unofficial repositories for using the
>> precompiled packages instead or something ^^.
>
> I am absolutely against replacing "reproducible" PKGBUILDs (those
> which do not generate variables on-the-fly and can be built in clean
> chroots and installed with predictable results) with
> "non-reproducible" PKGBUILDs (those which require user interaction, or
> use backquotes constructs to modify their source array or $pkgver).
>
> For me the latter category of PKGBUILDs are only convenience solutions
> (that are sometimes created to work around AUR limitations). They are
> certainly useful, and most of time welcome in the AUR, but will never
> in my mind replace true PKGBUILDs that correspond to deterministic and
> well-defined packages.
>
> A package should only be deleted if it is irrevocably broken or if a
> package exists that provide the same functionality *at the same level
> of reproducibility and predictability*.
>
> Rémy.
>
I agree with the concept. However, in your opinion does
nvidia-beta-all fall under non-reproducible? It does different things
on different machines, but entirely in a non-interactive way. In case
you don't want to bother to take a look at the PKGBUILD (I wouldn't),
here's the basic thing it does:-

1. grep through files in /boot/ to find installed kernels
2. compile the NVIDIA driver for those kernels

It cannot be compiled in a chroot (unless the requisite kernels are
available), but it seems to satisfy the rest of your criteria.

The discussion may be moot, however, since I just searched through the
AUR for nvidia and noticed most of said packages still have
maintainers (did not check whether they were out-of-date). No problem,
then.

I could possibly simply add white/black-listing to the PKGBUILD to
cater for those who want nouveau on specific systems (though AFAIK
this would require symlinking of libgl...). I hate PKGBUILDs which
interactively ask for anything, there should be a sane default
non-interactive behaviour, but also simple tweakables.

Re: [aur-general] Adopting the paccheck package

[Oon-Ee Ng]

On Sun, Mar 27, 2011 at 10:24 PM, Ionuț Bîru  wrote:
> On 03/27/2011 05:13 PM, Bernard Baeyens wrote:
>>
>> IgnorantGuru doesn't intend to continue maintaining the paccheck
>> package, which is now broken after the pacman 3.5.1 upgrade.
>>
>> I wrote an updated version which can be used with the new pacman release.
>> I agree to become the new maintainer of that package.
>>
>> Can you change that in the AUR please ?
>>
>>  Original Message from IgnorantGuru to me 
>> Subject: Re: Patch for paccheck after pacman udgrade to 3.5.1
>> Date: Sat, 26 Mar 2011 16:17:12 -0600
>> From: IgnorantGuru 
>> To: Bernard Baeyens 
>>
>>
>>
>> It looks like you might send an email to the AUR mailing list to
>> invoke the change. In case it helps...
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Bernard Baeyens  has my exclusive permission to
>> immediately
>> become the maintainer of my AUR package "paccheck". I do not
>> authorize it to
>> be transferred to any other user.
>>
>
>
> what a troll.
>
> Maintainers CAN disown the packages that they maintain.
>
> --
> Ionuț
>
He obviously does not know that. Most likely a failure to properly
read the relevant documentation and actually try things out
sufficiently =)

Re: [aur-general] Please remove firefox-bin

[Oon-Ee Ng]

On Sun, Mar 27, 2011 at 8:43 PM, Det  wrote:
> On 3/27/11, Ionuț Bîru  wrote:
>> i do prefer to have them in aur, but the maintainer should follow
>> firefox-bin as stable, firebox-beta-bin as beta.
>>
>> now there isn't any beta version available and it should be updated to
>> stable.
>
> Firefox-beta-bin has actually already been updated to 4.0.
>
>> is fine like it is now.
>
> The only difference between 'firefox-bin' and [extra]'s 'firefox' is
> that 'firefox-bin' is built by the Mozilla guys.
>
> But if you think that's enough, then I'm fine with it.
>
>   Det
>
That's typically the case for '*-bin' packages. Useful because some
projects ask that you use the pre-compiled packages from their site
first when submitting bug reports. Among other things.

Re: [aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?

[Oon-Ee Ng]

On Sun, Mar 27, 2011 at 5:28 PM, Det  wrote:
> On 3/26/11, Oon-Ee Ng  wrote:
>> I can assure you that nvidia-beta-all (and nvidia-all which Det
>> maintains) builds the modules for all installed kernels.
>
> I do? I didn't even know that. The "Maintainer: None" phrase was a
> little confusing to me ^^.
>
> Anyway, I posted an updated PKGBUILD for the maintainer who adopted
> the package while I was doing it.
>
>   Det
>

Ah, didn't you maintain it at one point? I remember seeing your name
in relation to it. The other time I see your name repeatedly is when
flagging my packages out-of-date =). Thanks by the way.

Re: [aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?

[Oon-Ee Ng]

On Sat, Mar 26, 2011 at 9:15 PM, Det  wrote:
> On 3/19/11, Ike Devolder  wrote:
>> For me its all the same, you can remove the nvidia-bede package
>> from aur
>>
>> i'll keep it in my own source tree because the nvidia-all package
>> assumes the kernel version as the running version
>>
>> most of the time i build for a kernen which is not running at the time
>>
>> Ike (aka BlackEagle)
>
> I would really like people to hand out more oppinions about this.
>
> This is implicating a lot of packages.
>
>        Det
>
Hmm, didn't see the email from Devolder. Having written the initial
nvidia-beta-all package, I can assure you that nvidia-beta-all (and
nvidia-all which Det maintains) builds the modules for all installed
kernels. uname -r is not used at all, a bit of sed hackery lists down
the installed kernels and builds nvidia modules for each of them.