Re: [aur-general] TU removal: Ray Rashif

[Ray Rashif via aur-general]

Sorry folks, I should have probably sent in a resignation for this. I
have also made unfulfilled promises as a developer and never sent in
an inactivity declaration in the hopes of getting back to Arch/Linux
once I have a new computer. As funny as it sounds my undeclared
inactivity is as long as this current machine ~3-4 years and a
purchase has been pending since last year but keeps getting
down-prioritized due to $$ requirements elsewhere in RL.

On Wed, 16 Oct 2019 at 22:30, David Runge  wrote:
>
> On 2019-10-11 14:44:27 (+0200), David Runge wrote:
> > In accordance to the bylaws a vote has now been started:
> > https://aur.archlinux.org/tu/?id=120
>
> The results are in:
>
> Yes: 36
> No: 7
> Abstain: 6
> Total: 49
> Participation: 87.50%
>
> The quorum of 66% has been reached with a larger number of "Yes", than
> "No" votes.
>
> This means Ray Rashif is no longer a Trusted User.
>
> On behalf of the team I would like to thank Ray for his dedication
> towards the community and distribution over the years.
>
> I hope that his time permits further involvement in the future. :)
>
> Bests,
> David
>
> --
> https://sleepmap.de



-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] TU Application: David Runge

[Ray Rashif via aur-general]

On 24 October 2017 at 22:54, Giancarlo Razzolini
 wrote:
> Em outubro 24, 2017 14:43 Rashif Ray Rahman escreveu:
>>
>> On 18 October 2017 at 18:40, Rashif Ray Rahman 
>> wrote:
>>>
>>> The discussion begins now and will last until 23 October, after which
>>> the voting period will begin on 24 October. Good luck David!
>>
>>
>> The formal discussion period is over, please cast your votes! The
>> voting period will last until 31 October.
>>
>> I do have one thing to say to David: please do think about the time
>> commitment associated with this. If you think that you won't be able
>> to commit much starting out, then it will be quite sad moving forward.
>>
>> Otherwise, I say again that David's proposal has followed standard
>> procedure, including a holistic review by myself the sponsor. Some
>> issues were raised based on automated tool reports, which I think
>> David will be able to resolve.
>>
>> Good luck!
>>
>
> The link to the vote for the lazy: https://aur.archlinux.org/tu/?id=97

Results are in:

Yes   No  Abstain  Total   Participation
  25 68  39   82.98%

Congratulations, David, you are now an Arch Linux Trusted User!

What's more:

- I have updated your account on AUR;
- I see you have two usernames on our bugtracker, let us know which
username to upgrade.

Enjoy!


-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] TU Application: David Runge

[Ray Rashif via aur-general]

On 25 October 2017 at 06:12, Eli Schwartz  wrote:
> On 10/24/2017 12:43 PM, Rashif Ray Rahman wrote:
>> Some issues were raised based on automated tool reports, which I
>> think David will be able to resolve.
>
> Excuse me? I am hardly an "automated tool report". :p You seem to have
> derived that conclusion out of thin air.

Ahh, crap. Before I get to that, automated tool or not, I forgot to thank you
for providing your feedback for David.

Now, about that automated tool thing: I did a search for 'xxarhtna' in my
archives and got some lines indicating an execution of a script. So,
it was not really out of thin air, but most likely my misinterpration.
It's likely my absence from IRC that's causing this faux pas.

But again, even if it were an automated tool report, it would have been
"issues based on automated tool reports", which is feedback nevertheless.
And for that one must be thanked.

> The reason I never got around to remarking on his packages until very
> nearly the last day of the discussion period was not just because I was
> expecting anthraxx to do so first -- I also spent no little time reading
> every single PKGBUILD of his in the AUR, and cloning the sources for
> perusal for several of them too.

No, of course, it's not wrong to not be able to commit to anything here.
If you choose to provide feedback that means you went out of your way.
And in this case you definitely went out of your way to support the
applicant's sponsor in raising concerns he did not, which is healthy.

> I've seen a lot of PKGBUILDs, and many/most of the simple mistakes or
> general style failures that people tend to make; I have a list of things
> to raise red flags over. But that still doesn't mean I can review a
> PKGBUILD without even looking at it! Maybe one day...

Again, that comment of mine was not really meant to say nobody did
anything. I really just wanted to say "issues were raised" or "feedback
was given". Me being a wordy person, sometimes extra words get added for free!

But yes, if there are indeed red flags that make the applicant
look totally incapable or untrustworthy, we should know, and
raise hell ourselves.


--
GPG/PGP ID: C0711BF1

Re: [aur-general] TU inactivity

[Ray Rashif]

On 31 July 2012 05:03, Kyle k...@gmx.ca wrote:
 Thanks for all you do to keep Arch talking. See you next week.

Yes, Chris, I just want to say you're an awesome guy (note: he was my
awesome TU sponsor) especially for creating and maintaing TalkingArch
and in general making awesome computing accessible. Take care and
enjoy!


--
GPG/PGP ID: C0711BF1

Re: [aur-general] orphaned community packages (intel-tbb, arpack, libmatio, xml-rpc and aspell-pt)

[Ray Rashif]

On 4 January 2012 08:23, Eduardo Martins Lopes edumlo...@yahoo.com.br wrote:
 Actually the question regarding the names is about creating an aur package
 with the same name of the orphaned ones since the aur is where i can
 maintain those packages.

Oh no you can't do that. You have to use a different name. For
packages that are out of date it is better to provide the maintainer
(via email or other means) with updated scripts or patches. If they
are not responsive then bring the matter up with everyone. One of us
can at least help to apply the changes verbatim.

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] orphaned community packages (intel-tbb, arpack, libmatio, xml-rpc and aspell-pt)

[Ray Rashif]

On 3 January 2012 07:39, Eduardo Martins Lopes edumlo...@yahoo.com.br wrote:
 Hello guys,
 I have an aur package 
 (opencv-tbb https://aur.archlinux.org/packages.php?ID=42121) that depends on 
 intel-tbb, but this one is an orphaned community package and i would like to 
 maintain it. Can i upload a pkbuild to the AUR (perhaps with the same name) ? 
 There a few other orphans that would like to adopt, if it's possible:
        * libmatio - http://www.archlinux.org/packages/community/i686/libmatio/
        * arpack  - http://www.archlinux.org/packages/community/i686/arpack/
        * xmlrpc-c - http://www.archlinux.org/packages/community/i686/xmlrpc-c/
        * aspell-pt - http://www.archlinux.org/packages/extra/i686/aspell-pt/
 Although i do not use the last ones (except for the dictionary), they fall 
 within the scope of my interests.

Hello

I was supposed to bring intel-tbb to extra and build opencv against
it. I will do that soon, so you don't have to worry about that one
anymore and opencv from repos will have intel-tbb improvement.

As for the others, it depends on the maintainer, the package
popularity, whether it is in use as a make or optional dependency etc.


--
GPG/PGP ID: C0711BF1

Re: [aur-general] Merry Christmas!

[Ray Rashif]

On 24 December 2011 22:28, Jesse Jaara jesse.ja...@gmail.com wrote:
 Merry christmas for every christian people. I hope people from another
 religion don't mind us wishing merry Christmas.

If they do, their at a loss - 'tis the season to be jolly ;p

Merry Christmas and happy holidays!


--
GPG/PGP ID: C0711BF1

Re: [aur-general] Christmas Cleanup of [community] - Stage 2

[Ray Rashif]

On 14 December 2011 21:55, Alexander Rødseth rods...@gmail.com wrote:

 Oh, and please update the table at

 https://wiki.archlinux.org/index.php/Christmas_Cleanup#Orphaned_community_packages_that_should_be_moved_to_unsupported
 once packages have been moved.

 Thanks. :)

 --
 Sincerely,
  Alexander Rødseth
  Arch Linux Trusted User
  (xyproto on IRC, trontonic on AUR)


Thanks, adopted cwiid which I forgot about :P

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] [PATCH] Added handling of ctrl-c

[Ray Rashif]

On 9 December 2011 19:27, Alexander Rødseth rods...@gmail.com wrote:
 Hi,

 2011/12/9 Angel Velásquez an...@archlinux.org:
 HAHA don't you realize that you're sending this thread to aur-general
 right?

 pwned. Glasses are good, you know? ahahaha

 I know, I wrote that the wiki also had it wrong, admitting my mistake.

At that time there was no projects mailing list to send patches, and
arch-general was this avenue until just recently. So that's not really
wrong.

Anyway, not a big issue. Send to the correct list again.

--
GPG/PGP ID: C0711BF1

Re: [aur-general] install recursive?

[Ray Rashif]

On 1 December 2011 01:25, Piotr Rogoża rogoza.pi...@gmail.com wrote:

 On 28.11.2011 21:38, Jonathan Steel wrote:
  Hi,
 
  I was told it was best practice to use install rather than mkdir
  and cp in a PKGBUILD, but how can you copy a directory and its
  contents (recursively) using install?
 
  If you cannot, with a folder with lots of files, is it best practice
  to list every file to copy with install, or use one command to cp
  the whole folder?

 Hi,

 Maybe tar? E.g.:
 tar -c ./ | tar -x -C ${pkgdir}/...

 --
 Piotr Rogoża


I think this is where we say enough :)

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] TU Application - Timothy Redaelli

[Ray Rashif]

On 30 November 2011 03:47, Timothy Redaelli timothy.redae...@gmail.comwrote:

 Hi,
 I'm sorry that I took too much inspiration from the presentation of
 Massimilano.
 It was not my intention to disrespect anyone. I've never been good at
 describing myself and I was looking for a starting point, but I think
 I overdid it.
 I hope I can prove worthy of trust, despite this incident.


Your English is perfect (you may have asked someone for help here but
that's out of the point).

I took a look at both applications, and it is evident that the older one
has been used as a template here. A template, nothing less, nothing more.
Keep in mind that both of these applicants are from the same community (I
presume), so one may think it's alright to do a little copying from the
person before him.

I believe there is no harm, because unique information has been
appropriately inserted as and where needed.

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] [arch-dev-public] Developer/TU key signing

[Ray Rashif]

On 25 November 2011 21:27, Ionut Biru ib...@archlinux.org wrote:
 Hi,

 my arch master key is available [1] with fingerprint 44D4 A033 AC14 0143
 9273  97D4 7EFD 567D 4C7E A887.

 Every packager please do:

 1) reply this email in the mailing list, include gerolde/sigurd username
 and sign your reply using your gpg key.
 2) name at least one package you already signed.

 [1] https://dev.archlinux.org/~ibiru/ionut_AT_master-key.archlinux.org


 --
 Ionuț



gerolde username: schivsigurd username: schiv
Package(s) already signed with key:
* extra/libffado
-- 
GPG/PGP ID: C0711BF1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

/home/schiv/.gnupg/pubring.gpg
- --
pub   2048R/C0711BF1 2011-10-31
  Key fingerprint = D921 CABE D130 A569 0EF1  896E 81AF 739E C071 1BF1
uid  Rashif Rahman (Ray) sc...@archlinux.org
sub   2048R/D1998B5D 2011-10-31

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJOyB75AAoJEIGvc57AcRvx9QIH/2YLLoPjKeCblhni8HDOyBZS
h00P5KdRionmBD2h04LKhL8kp1OD7TW77JKE3uWusgkR2QCJjv2Goo+4tOsLv9+u
5fNVLZFF1K9jKp88t9qWwvtr2tzAYArnUQHdkS175smoYkUIzkStkesiT0apLcqB
c3Wx0hm94YA6GB9MbXz/qY2IRDhb1ammDYfOAnFS9rHJT8mKRBKJTDdiWB9xM+Oo
BmTRSfWfq25OMW0IPtGlbo/z1Pwb9g7MnOfY+9o0/BImsDp/RUT/xtLAwscrTIKU
AarC5UZi5MZvJ2Hn2KjzrJ0pHi5bZVmi0dS6HscOyj8rx4JllKQieKK94EpLFFQ=
=LqPw
-END PGP SIGNATURE-

Re: [aur-general] Resigning as a TU

[Ray Rashif]

On 21 November 2011 02:17, Thorsten Töpper atsut...@freethoughts.de wrote:
 On Sun, 20 Nov 2011 16:02:58 +0100
 Stefan Husmann stefan-husm...@t-online.de wrote:

 Hello,

 I want to resign as a TU. I do not have the time anymore to fulfill
 my TU duties and to handle the new package signing stuff.

 By the way I suggest to remove the package scilab and maybe also the
 dependencies from the repos. There are long open bug reports, and they
 are unsolvable.

 Regards Stefan

 Makes me sad to read this, but I hope you have a good time. Thank
 you, I owe you a lot. :-)

 --
 Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/
 Key: 295AFBF4     FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4


Yes, Stefan, thank you for all your work. Good luck in everything!

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] TU Resignation

[Ray Rashif]

On 21 November 2011 00:10, Jelle van der Waa je...@vdwaa.nl wrote:
 On 19/11/11 19:44, Thomas S Hatch wrote:

 I have a lot of regret doing this, and I have been working hard to find
 the
 time to keep up with my TU duties, but every day I have less and less time
 because work is continually ramping up, and what free time I have left
 ends
 up going to Salt (http://saltstack.org).

 So, very sadly, I need to resign from my position as an Arch Linux TU. I
 hope I can be of assistance to Arch in the future and I am still planning
 on maintaining the Varch project: https://github.com/thatch45/varch

 So with deep regret, I must resign my brief stint as a TU, it was fun, and
 I greatly appreciate the opportunity, but it is very unfair of me to not
 be
 maintaining my packages.


 Thanks

 -Thomas S Hatch

 Sad to see you leave, good luck with Salt!

 --
 Jelle van der Waa


One awesome person less :(

Good luck with everything else!

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] Update request for supertuxkart

[Ray Rashif]

On 20 November 2011 03:29, Laurent Carlier lordhea...@gmail.com wrote:
 One solution should be to embed an irrlicht svn snapshot in supertuxkart
 package.

That is for upstream to do, if they're so dependent on devel versions
of software.


-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] Inactive / past TU

[Ray Rashif]

On 8 November 2011 23:38, Karol Blazewicz karol.blazew...@gmail.com wrote:
 Brad Fanella resigned two weeks ago [1] but he is still listed as an
 active TU - is that OK? Should I move him to inactive TUs or to past
 ones? I've e-mailed him on this mater two days after his resignation
 but got no response.

 [1] 
 http://mailman.archlinux.org/pipermail/aur-general/2011-October/016228.html
 [2] https://wiki.archlinux.org/index.php/Trusted_Users


Past ones.


-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] Request to add a rule

[Ray Rashif]

On 28 October 2011 23:55, Peter Lewis ple...@aur.archlinux.org wrote:
 On Fri, 28 Oct 2011, Christopher luna wrote:
 Im not even asking you to agree with me, Im asking you to vote and decide if
 including urls to warez on pkgbuilds that are on AUR is OFFICIALY ok, or not.

 again is not about they being propietary software or about providing
 installers. Is ONLY about urls to warez. they are ok or not?

 I think this is a legitimate question. But to be honest, despite what any of 
 us
 think, it should probably be answered by whoever legally is Archlinux.  
 Aaron,
 perhaps?

No need. Because...

* Uploading a Microsoft Office 2011 Retail PKGBUILD that retrieves
an archive containing cracked executables is WRONG.

* Uploading a Microsoft Office 2011 Retail PKGBUILD that does not
retrieve anything but has the file name of the archive containing
cracked executables as a source is WRONG.

* Uploading a Microsoft Office 2011 Runtime PKGBUILD that retrieves
an official *redistributable* archive containing clean executables is
RIGHT.

* Uploading a Microsoft Office 2011 Demo PKGBUID that retrieves an
official *non-redistributable* archive containing clean executables is
WRONG.

* Uploading a Microsoft Office 2011 Demo PKGBUILD that does not
retrieve anything but has the file name of the official
*non-redistributable* archive containing clean executables as source
is RIGHT.

Think of the these as a template checklist for your next AUR
restricted contribution, i.e apply where applicable.

Abandonware is nothing special. Some may be redistributed freely, some
not. When not, don't. Simple.

I agree that we need to have some sort of black and white on this, so
I've made a simple addition to the FAQ:

https://wiki.archlinux.org/index.php/Arch_User_Repository#Q:_What_kind_of_packages_are_permitted_on_the_AUR.3F


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Request to add a rule

[Ray Rashif]

On 29 October 2011 06:14, Ray Rashif sc...@archlinux.org wrote:
 * Uploading a Microsoft Office 2011 Demo PKGBUID that retrieves an
 official *non-redistributable* archive containing clean executables is
 WRONG.

Ammendment to this part:

* Uploading a Microsoft Office 2011 Demo PKGBUILD that retrieves
*from a third-party site* an official *non-redistributable* archive
containing clean executables is WRONG.

* Uploading a Microsoft Office 2011 Demo PKGBUILD that retrieves
*from the official site* an official *non-redistributable* archive
containing clean executables is RIGHT, *unless linking from
third-party sites is explicitly forbidden*.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] TU Resignation

[Ray Rashif]

On 25 October 2011 12:47, Brad Fanella bradfane...@archlinux.us wrote:
 p.s. there were some personal issues as well, but I don't really feel the
 need to get into those here ~ we can let Xyne speculate with one of his
 riveting stories

Sorry to hear about this especially. Anyway, thanks for all your work.
Take care and good luck!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] berlios is dying

[Ray Rashif]

On 14 October 2011 06:00, Andrea Scarpino and...@archlinux.org wrote:
 On Friday 14 October 2011 05:56:59 Ray Rashif wrote:
 Yes, I agree. This is important. Glad it's been brought up, I wasn't
 aware of this.
 I was, but we cannot do anything about. We've just to wait for upstream to
 move and, if they don't, on 31th December we'll put the old sources on al.org.
 IMHO.

Some of them should have alternate locations, so AL.org should be the
last resort (bandwidth is capped at around 512Kbps).


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] berlios is dying

[Ray Rashif]

On 14 October 2011 05:49, Sergej Pupykin m...@sergej.pp.ru wrote:
 On 14.10.2011 00:26, Stefan Husmann wrote:

 Hello,

 this is merly an upstream issue, but it might be good to be aware of it:

 berlios will be closed with the end of this year. See
 http://www.berlios.de/
 Projects hosted there will have to move elsewhere.

 In the repos the following packages will be affected:

 Hello,

 May be it would be better to add TODO on dev website so we can track status?

Yes, I agree. This is important. Glad it's been brought up, I wasn't
aware of this.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] TU Application - Massimiliano Torromeo

[Ray Rashif]

On 3 October 2011 23:56, Massimiliano Torromeo
massimiliano.torro...@gmail.com wrote:
 - ttf-ubuntu-font-family
 - e4rat
 - vdfuse
 - vbox-runner

Looking forward to those :)

Good luck!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Vote on Alexander Rødseth's (trontonic) TU application

[Ray Rashif]

On 17 September 2011 20:22, Evangelos Foutras evange...@foutrelis.com wrote:
 On 09/09/11 16:26, Evangelos Foutras wrote:
 Dear TUs,

 The discussion period for Alexander's TU application has ended.

 Please hop onto the web interface to vote:

 https://aur.archlinux.org/tu.php?id=49

 The voting period has ended, and the results are:

 Yes: 16
 No: 0
 Abstain: 3

 19 of the 28 TUs voted, quorum has been met, and Alexander is now a TU!

Welcome aboard, Alexander!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Kate Plugins Group

[Ray Rashif]

On 10 September 2011 02:04, Daniel Poulin crimsonm...@gmail.com wrote:
 Hi everyone,

 I'm writing a PKGBUILD for a kate plugin and noticed there are a few other
 kate plugins in AUR.  I also maintain a libreoffice plugin and noticed they
 are all part of a group (libreoffice-extensions). Should all of us kate
 plugin maintainers add the same group to our packages? Perhaps
 kdesdk-kate-plugins or simply kate-plugins?

I don't see why not :)


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [lmms] unmaintained

[Ray Rashif]

On 7 September 2011 17:18, Uli Armbruster uli.armbrus...@googlemail.com wrote:
 Lmms has been out of date for quite a while. It's been flagged out of date on 
 June 13th.
 I emailed the maintainer Mateusz Herych telling him that only the pkgver and 
 checksums
 have to be updated. He answered, that he's too busy in real life to take care 
 of it.

Yes, it can happen. The rest of us are here to help, and once you let
us know (if we are not aware already), we'll take care of it.

However, if that was his reply, then it should've been followed up by
a notification to let us know of his situation and to ask us for help
to keep his packages up-to-date, or at least those that are important.
By right, he should've marked himself busy/inactive.

Anyway, I've updated lmms for now and will keep on monitoring the
package since I'm familiar with it.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [lmms] unmaintained

[Ray Rashif]

On 7 September 2011 19:48, Sven-Hendrik Haase s...@lutzhaase.com wrote:
 Actually updating doesn't seem so straight forward as compilation for the most
 recent version breaks.

That's because it was never built in a chroot before, and those
optdeps need to be makedeps as well. Either that, or least likely,
upstream has just changed their buildsystem to check for those deps
during buildtime.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Merge request: ttf-ubuntu-font-family and ttf-ubuntu

[Ray Rashif]

On 7 September 2011 10:02, Jekyll Wu adap...@gmail.com wrote:
 ttf-ubuntu-font-family[1] and ttf-ubuntu[2] are essentially the same, except
 that the latter provides an outdated version.

 Please merge [2] into [1].

 [1] https://aur.archlinux.org/packages.php?ID=41465
 [2] https://aur.archlinux.org/packages.php?ID=47336

I think the older version is better according to some users so it remained.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Merge request: yakuake-git and yakuake-qt4-svn

[Ray Rashif]

On 6 September 2011 16:23, Jekyll Wu adap...@gmail.com wrote:
 yakuake-git[1] and yakuake-qt4-svn[2] are essentially the same. They both
 pull code from git://anongit.kde.org/yakuake.

 Since the upstream has switched from svn to git, I would suggest deleting
 the -svn package or merging it into the -git pakcage.

 [1] https://aur.archlinux.org/packages.php?ID=41530
 [2] https://aur.archlinux.org/packages.php?ID=30056

There is a problem. [1] looks like a bad PKGBUILD to me, with a make
after cmake. Also depends differ, so we need to know which is the
correct one to keep, or else the maintainer needs to update it.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Merge request: yakuake-git and yakuake-qt4-svn

[Ray Rashif]

2011/9/6 Lukáš Jirkovský l.jirkov...@gmail.com:
 On 6 September 2011 13:31, Ray Rashif sc...@archlinux.org wrote:
 On 6 September 2011 16:23, Jekyll Wu adap...@gmail.com wrote:

 There is a problem. [1] looks like a bad PKGBUILD to me, with a make
 after cmake.

 That is correct.

Ahh crap, yes, I actually meant the opposite:

s/[1]/[2]/
s/with/without/


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Securing the AUR website

[Ray Rashif]

On 3 September 2011 23:49, Gordon JC Pearce gordon...@gjcp.net wrote:
 One is that https is painfully slow over slow or unreliable connections (GPRS 
 springs to mind; 3G service is patchy here).
 The other is that switching to https has left AUR in a fundamentally broken 
 state.  If you search for a package on AUR with any of the significant search 
 engines, they return an http link.  You can't do anything with this, though, 
 because *even if you're logged in* you get the ZOMG OH NOES YOU AREN'T USING 
 HTTPS AND HTTPS IS TEH AWSUM11!!11! message.
 Now, if clicking on that took you *to the same page but with https* that 
 would be fine, but it doesn't.  It unceremoniously dumps you on the index 
 page for AUR, with no way to get back to the package that you googled.

 So, the only way to use AUR from (say) Google is to search for a package, 
 click on it, copy the address from the bar, click on the https login link, 
 log in (since even if you're logged in, visiting the http page seems to log 
 you out), then paste the address you got from the search engine into the 
 address bar, edit it to go to https, then hit return.  This is hardly a 
 seamless user experience, but it ought to be trivial to fix.

 Sort it the fuck out.

 If you want me to put my money where my mouth is and contribute some code, 
 then just ask.

You may want to file a bug report against the AUR project (or the
entire site) at http://bugs.archlinux.org/

If I just want to browse a domain or subdomain as a guest I wouldn't
want to deal with httpS because (1) it slows down my inherently slow
connection (think GPRS/EDGE/2G) and (2) I'm not even logged in to want
to protect any kind of credential.

As it is currently, the Arch Linux sites are enforcing HTTPS and so
even if I don't want SECURE, I have to deal with it. I didn't speak up
against this before because (1) I wasn't surfing around much and (2) I
didn't think my opinion/case would matter and (3) I don't even have
the sufficient technical knowledge to debate this sort of thing.

At the end of the day, though, SECURE for logins is definitely good,
but a lot of sites give the user an option to either disable or enable
httpS, eg. Google (GMail; GMail for Mobile) and WordPress. I also know
some sites where they only redirect paying or deluxe users to
HTTPS after/during login.

So even if you don't care about your password, it's good to have
HTTPS, just to be safe.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Securing the AUR website

[Ray Rashif]

On 5 September 2011 20:35, Pierre Schmitz pie...@archlinux.de wrote:
 On Mon, 5 Sep 2011 13:55:38 +0200, Cédric Girard wrote:
 Hi,

 On Mon, Sep 5, 2011 at 1:46 PM, Ray Rashif sc...@archlinux.org wrote:

 it slows down my inherently slow
 connection (think GPRS/EDGE/2G)


 Do you have any figures to support this? I would be interested to see what
 the impact of HTTPS on the client side is.

 Me too. We'd need some numbers to back this argument. I also wonder how
 many are really affected by having such a slow connection that this
 would actually matter. I wouldn't be surprised if this number is really
 low.

It just feels slower. I think the amount of data transferred does not
look that much bigger when you have at least a 512Kbps, but browsing
is indeed slower.

Take, for eg., GMail for Mobile on my phone has HTTPS disabled, and
when enabling it warns that more data will be used. A 128Kbps
unstable connection eg. over the GSM network will struggle with an
SSL-encrypted website far away from the user's ISP/region due to the
inevitable added latency of that kind of network.

However, you are right, there is no empirical evidence until I log my
connection to one of the Arch Linux sites with and without SSL. I will
try and do this soon.

In the meantime, these are Google results that you might've already come across:

http://support.microsoft.com/kb/150031
http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
http://serverfault.com/questions/43692/how-much-of-a-performance-hit-for-https-vs-http-for-apache


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] TU Application

[Ray Rashif]

On 4 September 2011 05:14, Philipp Überbacher hollun...@lavabit.com wrote:
 Being an audio person I've had a look at the first audio app in the list
 (cheesetracker) and I'm not entirely happy with the PKGBUILD. There's
 the minor thing that 'jack-audio-connection-kit' is just 'jack' since a
 couple of months. While I'm happy that you seemingly managed to get
 cheesetracker to build and while the 'addinclude' method is probably
 easy for packagers it's a very weird way to do things. Firstly it's
 an additional dependency from AUR, secondly it depends on another
 language that isn't wide spread yet (GO) while the same effect could be
 had without anything special (patch). To me this looks very much like an
 unnecessary 'because I can'-thing that makes installing the package more
 complicated than it needs to be.

And I can see that Alexander may be the tracker type.

Well, I have to agree with Philipp, and as has been told for
generations, a patch is much cleaner and is what we like to see over
multiple sed lines or a non-standard tool like 'addinclude' or
'setconf'. I'd pick clean-and-consistent over convenience, and I
believe that is the Arch Way I speak for. Your way is, of course, not
_wrong_ per se, as you would only have an additional (buildtime)
dependency. One may or may not choose to follow standard practices,
suggestions or recommendations.

Otherwise, packages mostly look good, and whatever deficiency you
might have right now, I'm sure for the kind of person you are (like
most of us troo Archers; just maybe more awesome) you'll pick things
up as you go ;)

I have a recommendation TODO for you:

1. milkytracker (we lack a tracker in the repos and is the most
popular of the bunch)

2. shedskin (very useful)

Also, I would like to say 'pruss one awesome' to your application and
profile/background.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Securing the AUR website

[Ray Rashif]

On 3 September 2011 09:29, Gordon JC Pearce gordon...@gjcp.net wrote:
 On Thu, 1 Sep 2011 20:36:34 +0200
 Cédric Girard girard.ced...@gmail.com wrote:

  What happens if you *don't want to use https*?
 

 I still have difficulties to understand why people would like to purposely
 avoid using https.

 I still have difficulties understanding why people would purposely use 
 https...
 What's the benefit?

I personally don't like https everywhere because its overhead is
significant for slow connections which I have to deal with. However,
I'm all for https logins because I wouldn't want my information to
be intercepted easily.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] TU Resignation

[Ray Rashif]

On 31 August 2011 09:11, Loui Chang louipc@gmail.com wrote:
 Hello everyone!

 I haven't been very involved with the AUR for a long while, and I don't
 really see that changing much. Since I only have a few packages I think
 it's time for me to resign as a TU. I may still throw a few patches
 around if I find the time. I've asked Lukas Fleischer to assume my duty
 of adding new TUs.

 It was a pleasure to work with you folks. See you around!

Although this is sad news, I wish you the best of luck in everything
else! You were instrumental in shaping the AUR and a figure I've seen
around from as far back as I can remember, so lots of thanks and
kudos!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Python packaging newbie

[Ray Rashif]

On 23 August 2011 07:03, Fabien Devaux fde...@gmail.com wrote:
 Hi!
 I'm new to arch  his packaging techniques and I have some questions on how
 things should be for python2/3 and build() vs package() things as well...
 Is this the good place to ask ?

If that is all your questions then this is the wrong place to ask. In
fact, it would then be wrong to even ask. It is only correct to read:

https://wiki.archlinux.org/index.php/Python_Package_Guidelines


--
GPG/PGP ID: 8AADBB10

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

[Ray Rashif]

On 11 August 2011 22:25, Lukas Fleischer archli...@cryptocrack.de 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.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Private mailing list for TUs?

[Ray Rashif]

On 12 August 2011 23:18, Florian Pritz bluew...@xinu.at wrote:
 Hi,

 I think it would be nice if we had a closed mailing list for TUs only
 (and maybe devs if they want to) so we can move more important stuff
 from IRC to mail because not everyone uses IRC or is online all the time.

 Keep in mind that it will likely be low traffic.

 Any hard feelings on that?

I have no strong opinions either way. However, I do feel there should
be an equal alternative to the IRC channel , which is private.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Deletion Request: old SuperCollider packages

[Ray Rashif]

On 29 July 2011 07:03, Bernardo Barros bernardobarr...@gmail.com wrote:
 old packages (sc uses git now):
 ---

 + sc3-plugins-svn
  http://aur.archlinux.org/packages.php?ID=36602

 + sced-svn
  http://aur.archlinux.org/packages.php?ID=29285

 + scvim-svn
  http://aur.archlinux.org/packages.php?ID=35130

 merged with sc3-plugins:
 ---

 + supercollider-dfm
  http://aur.archlinux.org/packages.php?ID=45931

Done!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] SuperCollider CleanUp 2

[Ray Rashif]

On 29 July 2011 22:35, Bernardo Barros bernardobarr...@gmail.com wrote:
 supercollider-with-extras-git
 http://aur.archlinux.org/packages.php?ID=48934

 supercollider-git-with-plugins-git
 http://aur.archlinux.org/packages.php?ID=44413

Deleted.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] PCSX2 Plugins folder - suggestion?

[Ray Rashif]

On 15 July 2011 10:32, rafael ff1 rafael.f...@gmail.com wrote:
 If the plugins are 32-bit, it's logical to put them in /usr/lib/pcsx2
 in 32-bit system. But in 64-bit system, I'm not sure if they whether I
 should put them in /usr/lib or /usrlib32/ (inside pcsx2 folder, of
 course).

32-bit libs-related stuff belong in /usr/lib32 on Arch64, nowhere else.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] PCSX2 Plugins folder - suggestion?

[Ray Rashif]

On 15 July 2011 16:35, Ray Rashif sc...@archlinux.org wrote:
 On 15 July 2011 10:32, rafael ff1 rafael.f...@gmail.com wrote:
 If the plugins are 32-bit, it's logical to put them in /usr/lib/pcsx2
 in 32-bit system. But in 64-bit system, I'm not sure if they whether I
 should put them in /usr/lib or /usrlib32/ (inside pcsx2 folder, of
 course).

 32-bit libs-related stuff belong in /usr/lib32 on Arch64, nowhere else.

See file list of
http://www.archlinux.org/packages/multilib/x86_64/lib32-alsa-plugins/


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Cleaning up wine packages

[Ray Rashif]

On 13 July 2011 15:47, Sven-Hendrik Haase s...@lutzhaase.com wrote:
 There are many wine packages in AUR and many of them are fairly old and/or
 obsolete, too.

 I'd like to clean that up. Here are the candidates:

 ...

 kwine (https://aur.archlinux.org/packages.php?ID=6498)
 Reason: Extremely old (2007), obsolete, dead upstream

 ...

 wine-doors (https://aur.archlinux.org/packages.php?ID=11823)
 Reason: Very old, dead upstream, dead source

Don't they still work? Are there alternatives to these two?


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Cleaning up wine packages

[Ray Rashif]

On 13 July 2011 16:31, Sven-Hendrik Haase s...@lutzhaase.com wrote:
 Neither is makeable. wine-doors misses source and its functionality now
 mostly exists in winetricks. kwine requires kwine-base which doesn't even
 exist. Also, KDE integration with wine is already a given anyway.

Ahh OK. To the trash with these, then!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] VCS Packaging Guidelines

[Ray Rashif]

On 2 July 2011 23:39, Mark Foxwell fastfre...@archlinux.org.uk wrote:
 I think that any _official_ view (even if it's 'either way is fine')
 should be added to the VCS PKGBUILD Guidelines wiki page [2].

Done:

https://wiki.archlinux.org/index.php?title=VCS_PKGBUILD_Guidelinesaction=historysubmitdiff=148014oldid=144799


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] python renaming

[Ray Rashif]

On 19 June 2011 21:09, Bernardo Barros bernardobarr...@gmail.com wrote:
 I think the solution is to be *very* consistent with packages names
 whatever the situation of the python3 version is right now.
 In other words: pick a guideline and stick to it. If
 python2-X/python-X is the way to go, no matter there is a python3
 package or not, use this convention...

Correct. However, with a previous discussion [1] and a bug report [2]
lingering I think most of us are hesitant to make any moves. Maybe
we're just hoping for someone to step up with a mighty roar and set
the record straight.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] python renaming

[Ray Rashif]

On 19 June 2011 21:09, Bernardo Barros bernardobarr...@gmail.com wrote:
 I think the solution is to be *very* consistent with packages names
 whatever the situation of the python3 version is right now.
 In other words: pick a guideline and stick to it. If
 python2-X/python-X is the way to go, no matter there is a python3
 package or not, use this convention...

Correct. However, with a previous discussion [1] and a bug report [2]
lingering I think most of us are hesitant to make a move. Maybe we're
just hoping for someone to step up with a mighty roar and set the
record straight.

[1] 
http://mailman.archlinux.org/pipermail/arch-dev-public/2011-April/019958.html
[2] https://bugs.archlinux.org/task/23139


--
GPG/PGP ID: 8AADBB10

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

[Ray Rashif]

On 17 June 2011 10:34, Thomas Dziedzic gos...@gmail.com wrote:
 On Thu, Jun 16, 2011 at 7:45 PM, Martti Kühne mysat...@gmail.com 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.


--
GPG/PGP ID: 8AADBB10

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

[Ray Rashif]

On 17 June 2011 20:56, Martti Kühne mysat...@gmail.com wrote:
 On Fri, Jun 17, 2011 at 9:00 AM, Oon-Ee Ng ngoonee.t...@gmail.com wrote:
 snip
 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.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Putting android development packages into [community]

[Ray Rashif]

On 10 June 2011 04:19, Sven-Hendrik Haase s...@lutzhaase.com wrote:
 Hi,

 I'm playing with the idea of pulling the android packages into [community].
 They seem to be in strong demand but so far their maintenance track in AUR
 has been fairly inconsistent.

 I'd like opinions on this because they have a rather large amount of votes.
 There have been license concerns about this endeavor but I think they are
 unfounded as all Android stuff (not including externals) is Apache license
 and thus ok to redistribute.
 Also, I'd like to know whether anybody thinks that instead of just
 repackaging the binaries, building from source would be preferable.

I'm a big proponent of this, so +1. I was hesitant about the
redistribution because I did not come across any distro redistributing
the suite on their repos. However, a quick e-mail to Google would
solve this.

Building from source would be useless and too cumbersome. Remember
that all this suite is about is (1) the SDK, (2) accompanying platform
libraries (currently 8 of them), (3) some accompanying tools (like
plug-ins for Eclipse).

I would like to propose an 'android-development' group (alongside
other probable android groups that may include stuff for end-users
like gmote-server), which would comprise:

1. android-sdk
2. android-sdk-platform-tools
3. android-{1.5,1.6,2.1,2.2,2.3,2.3.3,3.0,3.1)
4. eclipse-android
5. udev-android-rules (not sure if this is really needed)
6. android-ndk

Plus accompanying platform docs and examples. And anything else I
might've missed. Basically, one group to start developing for Android.

One may argue that there is no need to include the platforms, their
docs and examples, as they can be downloaded with the AVD Manager.
However, I say that it makes life for the developer on Arch Linux much
easier. You can pacman -S everything and start Eclipse, put in the
Android path, configure the AVD, and you're all set. Also, this way,
the setup is very portable since you can deploy this same environment
on another Arch Linux system very quickly when you have the packages
cached. In short, I'm thinking offline setup.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Putting android development packages into [community]

[Ray Rashif]

On 10 June 2011 04:56, Ray Rashif sc...@archlinux.org wrote:
 3. android-{1.5,1.6,2.1,2.2,2.3,2.3.3,3.0,3.1)

I think this is a bit too much. This is better:

3. android-{1.5,2.1,2.2,2.3)

1.5 == to target a larger range of devices
2.1,2.2,2.3 (or 2.3.3 or 2.3.4 if those exist as separate archives) ==
current popular platforms

As noted from: 
http://en.wikipedia.org/wiki/Android_(operating_system)#Usage_share



--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [AUR] Orphan all old packages flagged as out-of-date

[Ray Rashif]

On 7 June 2011 18:14, Andrea Scarpino and...@archlinux.org wrote:
 Hi TUs,
 I'd like to orphan all packages in AUR flagged as out-of-date before February
 2011 (for example, I think 3 months are enough).

I find 3 months are not enough (for a busy person). 6 is a nicer
number, i.e half a year, plenty of time for short bursts of free time
(for a busy person).


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [PATCH 1/1] TUs can change package names

[Ray Rashif]

On 1 June 2011 23:36, Jakob Gruber jakob.gru...@gmail.com wrote:
 On 06/01/2011 05:26 PM, D. Can Celasun wrote:

 Actually, it is still possible. Here's how it'd work:

 - TU changes package name from foo to bar.
 - This automatically triggers an out-of-date notification (and an
 explanation comment) for all packages that depend on foo.
 - Everyone updates their packages to reflect the changes.

 Now all votes, comments and even notification lists are preserved without
 doing a single database query. I really don't think it gets more KISS than
 that.

 I beg to differ. The way it is right now is way more KISS.
 So far, my favorite suggestion is either 1) creating a way to transfer votes
 and comments or 2) keeping everything as it is.

How about marking a checkbox upon upload where it would present a text
box to rename from an older package to the current one?

x Rename package from ||

If this from field MATCHES the pkgname being submitted then as usual
nothing would be done (submission as usual as if nothing had been
marked; package would be created if it does not exist).

If it does NOT MATCH, then a rename function (such as the one this
patch demonstrates) would be applied to that older pkg and then the
submission continues. Of course, the older package must be owned by
the currently logged in user. If the older pkg entered does not exist
in the db then the submission fails. If a package gets wrongly renamed
then the user can go through the same steps to rename that. No TU
involvement here.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] The Unarchiver and provides field

[Ray Rashif]

2011/5/23 Cédric Girard girard.ced...@gmail.com:
 As this application provides an unrar functionnality, does it make sense to
 add a provides=('unrar') field in the PKGBUILD? The Unarchiver is not a
 drop-in replacement for the unrar command. The binary are not the same and
 the syntax is different.

Absolutely no point in a provision, then.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] optional dependencies that require explicit installation

[Ray Rashif]

On 17 May 2011 18:14, Michael Schubert mschu@gmail.com wrote:
 2011/5/17 Ray Rashif sc...@archlinux.org


 That's the way it's done. You have those optdeps as makedeps so you
 can finish building the package.


 Sorry if I was a bit unclear earlier. The make process does not need all
 binding languages as dependencies as cmake and configure take care of
 preventing those from being built. So the make works fine with no optional
 dependencies installed.

When you're distributing any modular package that, when installed with
all usable dependencies, would provide full software functionality,
someone (the builder/packager) has to initially configure and build
the software with everything in place.

* So, you first install all usable deps, build it, then remove the
unimportant deps (thus making them makedeps + optdeps).

If a dep cannot be removed (when a particular part of the software
complains about something missing or does not work as expected), then
it cannot be an optional dependency. Sometimes, in order to appease
everyone, you must build and depend on deps that not everyone would
need, because those deps are link-level or hardcoded once used (to
build).
.
You don't have to build multiple packages just because of this, unless
we're talking about a rather large software compilation/bundle.

But yes, you may split the package in the end. If it is easier for you
then build as many times within the PKGBUILD as needed, to for example
a different directory each time. Then you can package separately and
the result is a split package. Do this only if building in the
optional support actually leads to unwanted bulk for those not needing
the optional functionality.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] optional dependencies that require explicit installation

[Ray Rashif]

On 17 May 2011 05:20, Michael Schubert mschu@gmail.com wrote:
 2011/5/16 jesse jaara jesse.ja...@gmail.com

 Put them as make and optional deps :-)


 But make doesn't depend on them. Also, I wouldn't want to install some
 weird programming language in order to get the package to build.

That's the way it's done. You have those optdeps as makedeps so you
can finish building the package. These deps will be installed as deps,
so a -Qdt would show them as orphans. There is --rmdeps that takes
care of this; makepkg -sr.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Aurphan in community

[Ray Rashif]

On 6 May 2011 21:13, keenerd keen...@gmail.com wrote:
 On 5/6/11, Ray Rashif sc...@archlinux.org wrote:
 Let me just confirm this: it is the first of its kind, in that it
 communicates with the AUR. There is no other tool in the repos that
 makes a connection to the AUR, right?

 Well that depends.  Do you count community/arch-firefox-search, which
 does a full search of the AUR?  (On an unrelated note, why is
 searching the AUR in a GUI officially supported but searching it from
 the CLI a mortal sin?)

Yes, I'd count that.

Now, on the unrelated note: the search engine is for a web browser,
and is in line with the AUR web interface. This interaction with the
AUR is indirect. That is why it is _not_ on a grey area.

A tool searching from the CLI (with which one has direct access), is
on a grey area. That is IMO; no consensus has been reached with
regards to whether searching can be accepted/supported (officially) -
only discussions.

 Aurphan does not search the AUR, it organizes info about the AUR
 packages you already have installed.  It does not imply AUR packages
 are supported, it asks you to volunteer support for them.

Yes, it initiates a connection to the AUR, that is all. I have nothing
against this myself, so +1.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Package Removal Request: some Faenza packages

[Ray Rashif]

On 3 May 2011 23:37, Kwpolska kwpol...@gmail.com wrote:
 faenza-k... hxxp://aur.archlinux.org/packages.php?ID=47201 (still not sure!)

And what prompted you to think it _might_ need deletion?


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Aurphan in community

[Ray Rashif]

On 30 April 2011 17:48, Stefan Husmann stefan-husm...@t-online.de wrote:
 Am 30.04.2011 10:10, schrieb Allan McRae:

 On 30/04/11 17:36, Loui Chang wrote:

 On Sat 30 Apr 2011 16:12 +1000, Allan McRae wrote:

 On 30/04/11 12:25, Loui Chang wrote:

 On Fri 29 Apr 2011 21:49 -0400, keenerd wrote:

 I would like to move Aurphan into community. I've added a number of
 features to it lately, and it has become an automated means of
 answering what can I do to help Arch, parsing and summarizing the
 todo list, the bugtracker and the orphans. The one random dev I've
 asked seems cool with it, however he thought a wider consensus should
 be found. It has enough votes but

 Aurphan could be considered an AUR helper. By default it searches the
 AUR for AUR packages you already have installed. It does not download
 anything.

 I will change it so the default behavior does not search the AUR.
 (New default would display the --help) I won't change the name, on
 account of it being cute.

 aur page: http://aur.archlinux.org/packages.php?ID=43726
 project page: http://kmkeen.com/aurphan/

 This script seems like a really nice idea, but if it deals with
 unsupported packages it should remain in that domain. Maybe move the
 functionality that deals with unsupported into an add-on that you can
 install separately?

 We should also drop wget, curl and firefox from the repos as they can be
 used to download unsupported packages... In fact, this script is safer
 because it does not even do that.

 Allan, I appreciate your work but you completely missed the point.
 wget, curl and firefox do not contain functionality to specifically
 access the unsupported packages. They are general network programs.

 I guess it depends on what your vision is. If you want more people
 expecting support for unsupported packages, then put these scripts into
 extra or community. I can't stop you, I'm just a lowly nobody and you're
 a big bad dev.

 My point was that (as far as I can tell) this software does nothing with
 AUR packages other than collates a bit of information. It does not allow
 downloading or building packages. I find it difficult to see how this could
 be seen as supporting AUR packages.

 Allan


 I think aurphan does not support aur packages but it eases to have better
 quality of the AUR as such, in recruiting more maintainers and having less
 orphaned packages there. We should support this. So go for it, Kyle!

Let me just confirm this: it is the first of its kind, in that it
communicates with the AUR. There is no other tool in the repos that
makes a connection to the AUR, right?


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Leave of absence

[Ray Rashif]

On 23 April 2011 13:48, Thomas S Hatch thatc...@gmail.com wrote:
 I will be unavailable for a few days next week. Last year I had a surgery
 which left my left vocal chord paralyzed. Unfortunately my vocal chord has
 not healed and I am going to have to get a silicone implant in my voice box
 so that I can talk again. My surgery is on Monday the 25th and I will be
 resting up for a few days afterward before resuming regular TU work.

 As for my fellow TUs, if my packages are out of date please feel free to
 update them, but I will be back soon!

 If you are interested here is a link describing the procedure:

 http://www.evmsent.org/uvfi_treat.asp

Get well soon! Awesome people should not be away for too long.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] VCS dupes in the AUR

[Ray Rashif]

On 11 April 2011 18:15, Lukas Fleischer archli...@cryptocrack.de wrote:
 * schismtracker-cvs https://aur.archlinux.org/packages.php?ID=19499
 * scikits-audiolab-svn https://aur.archlinux.org/packages.php?ID=21018
 * supercollider-git-with-plugins-svn 
 https://aur.archlinux.org/packages.php?ID=43637
 * qjackctl-cvs https://aur.archlinux.org/packages.php?ID=26766

Deleted.


--
GPG/PGP ID: 8AADBB10

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

[Ray Rashif]

On 5 April 2011 18:00, Oon-Ee Ng ngoonee.t...@gmail.com wrote:
 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.

+1

Exactly why I haven't had an offline e-mail client for some time.
Except for mutt which I keep around for the rainy day.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] When should pkgrel be updated?

[Ray Rashif]

On 1 April 2011 08:12, Oon-Ee Ng ngoonee.t...@gmail.com wrote:
 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's really very simple - you only need to remember this:

Whenever the resulting binary changes (in an important way) for the
user, you bump pkgrel.

Examples:

* Changing pkgdesc - do NOT bump (unless it's severely wrong or something)

* Changing deps - bump

* Changing makedeps - do NOT bump, ever

* Changing optdeps - do NOT bump (unless very important functionality provided)

* Changing build stuff (i.e changing PKGBUILD but no change to
resulting binary) - do NOT bump

If in doubt about more scenarios, please describe them.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] When should pkgrel be updated?

[Ray Rashif]

On 1 April 2011 23:48, Thomas S Hatch thatc...@gmail.com wrote:
 On Fri, Apr 1, 2011 at 9:39 AM, Dave Reisner d...@falconindy.com wrote:

 On Fri, Apr 01, 2011 at 05:31:34PM +0200, Jelle van der Waa wrote:
  On Fri, 2011-04-01 at 12:21 -0300, Denis A. Altoé Falqueto wrote:
   On Fri, Apr 1, 2011 at 4:12 AM, Ray Rashif sc...@archlinux.org
 wrote:
On 1 April 2011 08:12, Oon-Ee Ng ngoonee.t...@gmail.com wrote:
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 changand makes
 pkgrel=3
   
It's really very simple - you only need to remember this:
   
Whenever the resulting binary changes (in an important way) for the
user, you bump pkgrel.
   
Examples:
   
* Changing pkgdesc - do NOT bump (unless it's severely wrong or
 something)
   
* Changing deps - bump
   
* Changing makedeps - do NOT bump, ever
   
* Changing optdeps - do NOT bump (unless very important
 functionality provided)
   
* Changing build stuff (i.e changing PKGBUILD but no change to
resulting binary) - do NOT bump
  
   Are you sure about that? I would bump pkgrel in all your examples,
   except the first. Even though they may not change the resulting
   binary, they change how they are built. I always thought of pkgrel as
   a way to differentiate between versions of PKGBUILDs.
  
 
  a Makedep isn't that important so i wouldn't bump there, just like the
  build stuff. And if someone used ABS the makedep fix would be already
  there in svn ;)
 
  --
  Jelle van der Waa
 

 A change in makedeps might fix a broken build, or it might enable a new
 feature that's conditionally linked in based on the presence of the dep.
 Definitely seems worthy of a pkgrel bump.

 dave


 When packaging it is critical to ensure that the resulting package is
 consistent regardless of the build environment, this means the build can
 change based on what deps are installed, for instance I have seen many
 PKGBUILDS create different packages because software to facilitate language
 bindings were not present.
 This would mean that the makedeps need to fulfill the configuration of the
 package source, and adding/changing makedeps can have direct influence on
 the resulting binary.

 I would recommend that the only time one should not bump the pkgrel is if
 the changes are menial and completely contained in the PKGBUILD, and that if
 the packager is unsure, bump the pkgrel.

Changing makedeps that affect the resulting binary is considered
changing deps. So that's different, and you must bump.

The bottomline is that if only the build scripting changes, but not
the package itself, there is no need to bump. If you want to make your
changes show up in ABS, just release the buildscripts. Otherwise, you
can tell users to checkout from svn.

It's the same for AUR users. If a build breaks, just update your
PKGBUILD without a pkgrel bump. Old users will keep on running the
software undisturbed, new users will get the new PKGBUILD. A broken
build does not affect those who already have the package installed.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Dropping multiget

[Ray Rashif]

On 29 March 2011 15:09, Stefan Husmann stefan-husm...@t-online.de wrote:
 Hello,

 I would like to drop the multiget package from [community] for the following 
 reasons.

 - the tarball does not build. The error consist in a missing header file and
 was reported twice on upstream bugtracker without an answer

 - the latest svn-checkout builds, but the revision number is still low, it is 
 3.

 So what do you think? Should I upload a svn-based PKGBUILD or drop the 
 package?
 In svn there is a desktop file, which never made it to the tarball. This
 would at least allow me to remove multiget from the list in FS#23387.

Upload an svn-based PKGBUILD. multiget is one of the very few download
managers that can be compared to stuff like IDM, FDM. In fact, other
than fatrat, I think it's the only other one. I say we should try and
keep this maintained if it's not too troublesome.

Re: [aur-general] Packaging with DKMS support

[Ray Rashif]

On 24 March 2011 09:16, Jason Melton jason.mel...@gmail.com wrote:
 Hello,

 Over on the rtl8192se package[1], we have been discussing how to best
 support DKMS in packaging (at the AUR level), and I would like to ask
 for wider and more experienced comments. I have put my thoughts here
 and in more detail on my personal Arch wiki page[2].

Good job. I personally have no objections to standardising this. All
it would require is for packagers to incorporate a bit more typing for
module packages only. If we have a library system in place for
makepkg/pacman this could've been templated for use with one-liners.

Re: [aur-general] svn tweak

[Ray Rashif]

On 21 March 2011 00:18, keenerd keen...@gmail.com wrote:
 It seems accidentally commiting package binaries is an easy error
 among new TUs.

Never heard of this accident. New TUs should always clear things up
before jumping in. One or two mistakes are fine.

Is the packaging workflow not clear enough from the guidelines? Two
distinct steps for PKGBUILDs and binaries respectively:

* SVN (commit) for buildscripts
** SVN (archrelease) to finalise

* SSH (scp) for packages
** SSH (db-update) to distribute

Now, if you accidentally make the addition after a build, and then
commit, you have to change your habit. Make the addition, then do the
build, then commit (using devtools).

Re: [aur-general] svn tweak

[Ray Rashif]

On 21 March 2011 17:15, Peter Lewis ple...@aur.archlinux.org wrote:
 I have to admit (and I don't intend to offend anyone) that I found it a little
 confusing at first, though the how to be a packager page appears to have
 become a little clearer recently :-)

IMO it would be less confusing if there were one whole article just
about packaging workflow; it should not be TU/community- or
dev/extra-specific.

Re: [aur-general] How should *-devel packages generally be handled?

[Ray Rashif]

2011/3/16 Ng Oon-Ee ngoo...@gmail.com:
 So let's say foo is at version 4.0 (stable), should foo-devel stay at
 3.9 (the last beta/rc/unstable release) or update to 4.0?

Stay at the last unstable release.

Re: [aur-general] AUR 1.8.1 - Can No Longer Upload Packages

[Ray Rashif]

On 14 March 2011 10:32, Heiko Baums li...@baums-on-web.de wrote:
 Could the reason be some syntax errors?
 There are a lot of quotation marks too much. And the settings of your
 quotation marks seem to be quite inconsistent.

It would be funny if the AUR rejected PKGBUILDs due to syntax errors
or inconsistency [1], especially this one where curly braces and
double quotes merely dictate whether the build succeeds - not whether
it is a valid PKGBUILD.

On 14 March 2011 11:44, Tony C crt@gmail.com wrote:
 Apologies for the noise. AUR does not reject my package now after first
 creating the directory name for the package I have. I do not ever
 remember needing to create a special directory before. So I simply did
 mkdir package-name and tar'd that up containing my source files.

That does not tally with what you confirmed with us earlier - that you
had tried 'makepkg --source'.

[1] 
http://mailman.archlinux.org/pipermail/arch-general/2010-February/011272.html

Re: [aur-general] package submission

[Ray Rashif]

On 4 March 2011 01:01, Bernardo Barros bernardobarr...@gmail.com wrote:
 Yes, maybe more like tags not categories. We from pro audio miss a
 more specific category too, like pro audio, since multimedia is much
 to much to much broad!!

Not really. It is still under Multimedia, generally. Only in
technical circles does it get more cognitive and/or disciplined
relationships, like Electronics and Engineering. As far as we're
talking about software, it's all just multimedia :)

Re: [aur-general] [arch-general] Adding AUR packages to [community] packages' provides

[Ray Rashif]

On 25 February 2011 19:12, Lukas Fleischer archli...@cryptocrack.de wrote:
 Seriously, we should be consistent here.

I agree.

* Provide/replace/conflict as necessary when promoting a package from
AUR (eg. when renaming the package)

* Bump pkgrel OR force (I vote for force) for the first time (eg. so
users get the repo versions and not report bugs many days later while
still using the AUR package)

* Do NOT provide/conflict/replace just because of a FR for a package
in AUR (unless the request is to provide for a package name that is
aknowledged by many)

Re: [aur-general] [arch-general] Adding AUR packages to [community] packages' provides

[Ray Rashif]

On 26 February 2011 17:40, Allan McRae al...@archlinux.org wrote:
 On 26/02/11 19:22, Ray Rashif wrote:

 * Bump pkgrel OR force (I vote for force) for the first time (eg. so
 users get the repo versions and not report bugs many days later while
 still using the AUR package)

 Forces is crap (and dead in the future pacman-3.5).  Bumping the pkgrel
 should not be an issue given the package probably is frequently updated if
 it is worth bring to the repos, so it will have a pkgrel of 1 again soon.

Ahh right..force - epoch.

There have been a few cases where the AUR package is pkgrel=n and the
repo is pkgrel=k, and the package on the system is not updated along
with the move because k=1 or k=n. Then someone files a bug, which
later turns out to be applicable only to the AUR package. So here I
would start out with k=n+1, at least until we have a better way.

Re: [aur-general] Upgraded AUR to 1.8.0

[Ray Rashif]

On 22 February 2011 02:06, Lukas Fleischer archli...@cryptocrack.de wrote:
 On Tue, Feb 22, 2011 at 02:03:38AM +0800, Ray Rashif wrote:
 On 21 February 2011 18:08, Dieter Plaetinck die...@plaetinck.be wrote:
  On Mon, 21 Feb 2011 10:47:50 +0100
  Lukas Fleischer archli...@cryptocrack.de wrote:
 
  The official Arch Linux AUR setup has been upgraded to 1.8.0. For a
  short list of changes, read [1].
 
  Please report any issues on the AUR bug tracker [2].
 
  [1]
  http://mailman.archlinux.org/pipermail/aur-dev/2011-February/001433.html
  [2] https://bugs.archlinux.org/index.php?project=2
 
  what's the reasoning behind no longer showing all files in the source
  package? I found this feature quite useful.

 I've _always_ used this, almost on every package I came across. I
 don't want to be downloading anything I just want to take a rough look
 at. Would be good to have this back in some way or another.
 Brainstorm!

 Did you read all my replies on this topic? If you still think that this
 should be implemented no matter what, you'd better open a feature
 request on the bug tracker.

You do not really address this issue aside from shrugging it off as an
unneeded feature that costs one or two vulnerabilities. If it was
really that useless it would not have been implemented in the first
place. The loopholes are real, but the feature should not be
forgotten.

I will leave it up to the community to file a request to have this
back, because with that we can really see whether it actually is as
useful as a few of us claim :)

Re: [aur-general] Request: Package Revision

[Ray Rashif]

On 14 February 2011 01:09, Philipp Überbacher hollun...@lavabit.com wrote:
 Excerpts from Bernardo Barros's message of 2011-02-13 16:56:09 +0100:
 Hi all,

 I don't know much about Java.. but I wanted to package this one
 because of SuperCollider and it seems a good sound editor anyway.
 Please people with experience with Java and Java packages revise this
 one:

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

 thanks!
 Bernardo

 I don't have java-specific packaging experience, but I seriously wonder
 what this is supposed to achieve:
  cat  EOF  $pkgdir/usr/bin/${pkgname}
  #!/bin/bash
  cd /usr/share/$pkgname  java -jar Eisenkraut.jar
  EOF

This is a shortcut to create an executable for the java binary. Not illegal :)

Re: [aur-general] AUR Copyright

[Ray Rashif]

2011/2/7 Lukáš Jirkovský l.jirkov...@gmail.com:
 I think most PKGBUILDs are too simple to be considered software.

Simple or not, PKGBUILDs are scripts, and hence software. IMNSHO if
you must apply a license to PKGBUILDs, it should be that of makepkg's
OR the distribution's (for another distribution using makepkg and
similar buildscripts they will have the copyright).

Magnus Therming mentioned this on another thread, and I believe he
makes a valid statement when he says the buildscripts are assumed to
inherit GPL and so need no mention of it.

Re: [aur-general] AUR Copyright

[Ray Rashif]

2011/2/7 Lukáš Jirkovský l.jirkov...@gmail.com:
 I don't think it matters whether PKGBUILDs are software or not.

It never did, but now it does :)

 That sounds to me like saying all bash scripts have to be under GPL,
 because BASH is licensed under GPL.

If you want to look at it that way, then sure.

Re: [aur-general] Moving packages to Community

[Ray Rashif]

On 8 February 2011 03:23, Thomas Dziedzic gos...@gmail.com wrote:
 Side note:
 Although TUs are a great bunch, I don't think that's the main reason
 why people use the AUR. :)

As much as I'd like for this thread to die, because the main issue was
settled very many replies ago (we all agree that it's bad and we'll
make sure it doesn't happen again), I'd also like to stress the fact
that often times discussions veer off-topic and change in tone due to
a cultural and language barrier. So, chill out :)

Re: [aur-general] AUR Copyright

[Ray Rashif]

On 8 February 2011 03:47, Michael Witten mfwit...@gmail.com wrote:
 On Mon, Feb 7, 2011 at 09:29, Kaiting Chen kaitocr...@gmail.com wrote:
 On Mon, Feb 7, 2011 at 9:28 AM, Michael Witten mfwit...@gmail.com wrote:

 See my gcc-svn PKGBUILD:

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

 Nobody likes it anyway, so who cares! :-)


 Dude please don't try to make any policy decisions on your own. We still
 haven't decided what the policy will be regarding PKGBUILD licenses uploaded
 to the AUR. --Kaiting.

 I made that decision nearly 2 years ago, long before any of you even
 thought of starting this discussion.

 Besides, I was merely providing a counterexample to Ray Rashif's
 statement: 'First of all, we've never
 had people claiming rights to PKGBUILDs.'

But you kept quiet, you see. That's the point.

Re: [aur-general] Errors on submission: Invalid name: only lowercase letters are allowed

[Ray Rashif]

On 6 February 2011 14:27, andrew thomas atswa...@gmail.com wrote:
 I tried adopted this package (kernel26-yi)

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

 But when I tried to upload an updated PKGBUILD. I got rejected with
 Invalid name: only lowercase letters are allowed
 I used makepkg --source to generate a file named
 kernel26-yi-2.6.37-1.src.tar.gz.

 Why am I receiving this error?

Please pastebin the updated PKGBUILD. And have you disowned it again?
Else, please remember to adopt using the button - you don't adopt a
PKGBUILD by just submitting it.

Re: [aur-general] AUR Copyright

[Ray Rashif]

On 7 February 2011 02:38, Thomas S Hatch thatc...@gmail.com wrote:
 You raise a good point, I would think that we would need to post something
 on the submit page stating the copyright nature. My brothers are lawyers, I
 will check with them as to what the right thing to do is.

 -Thomas S Hatch
 On Feb 6, 2011 10:49 AM, Xyne x...@archlinux.ca wrote:
 Eric Waller wrote:

 I am not a lawyer and I generally tune out all license flame wars.
 That said, PKGBUILDS generally do not contain copyright or license
 declarations. Unless I am mistaken, that means someone who comes into
 possession of a PKGBUILD does not have the right to republish it.

 As a minimum, I think Arch should get a nod from the creator of a
 PKGBUILD prior to absorbing it into the colective -- It might help
 avoid any misunderstandings.

 What is the legal status of files submitted to the AUR? I have always
 assumed
 that anything uploaded to the AUR is automatically licensed under the GPL
 or
 something similar, in the same way that content contributed to the wiki
 is.

 I can't find anything that states this on the AUR site, which is a
 potentially
 calamitous legal oversight.

 The legal issue should be cleared up. If we needed to obtain explicit
 permission from every contributor then the AUR would cease to be useful.
 You
 would not be able to adopt and update PKGBUILDs without permission, and
 you
 would need to enable users to delete their own PKGBUILDs when they decide
 to
 withdraw permission.



Err..it is as relaxed as the wiki. I don't see why any question about
ownership should arise. If someone wants to claim ownership and not be
willing to share then so be it (don't even upload to AUR then). She
will have a bad reputation, not our problem.

Re: [aur-general] AUR Copyright

[Ray Rashif]

2011/2/7 Cédric Girard girard.ced...@gmail.com:
 On Sun, Feb 6, 2011 at 8:47 PM, Ray Rashif sc...@archlinux.org wrote:

 Err..it is as relaxed as the wiki. I don't see why any question about
 ownership should arise. If someone wants to claim ownership and not be
 willing to share then so be it (don't even upload to AUR then). She
 will have a bad reputation, not our problem.


 You can't say that. If someone decide to claim ownership to the PKGBUILD he
 wrote and nothing has been done to clear the ownership issue before, the
 reputation of this guy would be the last thing to worry about for Arch
 Linux.

 Considering the wiki, it is clearly stated as being under the GNU Free
 Documentation License 1.2.

Sorry, bad comparison, then. I'm not really sure what to compare it
with. We've never had to talk about things like this before (so
probably the time has come you would say). First of all, we've never
had people claiming rights to PKGBUILDs.

Re: [aur-general] AUR Copyright

[Ray Rashif]

On 7 February 2011 07:21, Xyne x...@archlinux.ca wrote:
 Ray Rashif wrote:

 Sorry, bad comparison, then. I'm not really sure what to compare it
 with. We've never had to talk about things like this before (so
 probably the time has come you would say). First of all, we've never
 had people claiming rights to PKGBUILDs.

 I agree that it is unlikely to be a problem, but the best thing to do is
 deal with the eventuality rather than continue with naive optimism.

 What needs to be done, imo:
 * decide on a permissive license or public domain for submitted files
 * add a clearly visible notification
 * add a note concerning the submission of files that cannot be redistributed,
  e.g. a copyrighted icon included in the upload
 * hope that no previous author ever shows up to claim copyright before the
  addition of the notice

Here is what Gentoo does for all their official ebuilds [1]:

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

This also appears in all third-party ebuilds [2], so I would assume
one written by an individual and distributed by itself would contain
this same license note.

In order for something like this to work for Arch, aside from official
and third-party repositories, the AUR needs to (1) reject PKGBUILDs
without the license header, (2) inject the header to every submitted
PKGBUILD, or (3) display a note and assume contributors will take the
initiative. None of those appeal to me, personally, but as far as this
subject is concerned I abstain :)

[1] http://gentoo-portage.com/
[2] http://en.gentoo-wiki.com/wiki/List_of_overlays

Re: [aur-general] Moving packages to Community

[Ray Rashif]

On 6 February 2011 02:31, Gergely Imreh imr...@gmail.com wrote:
 Hi,

 Recently a couple of my packages have been moved to Community but the
 process feels a little uneasy to me.

This has come up a couple of times before, and we all know it is very
wrong to move a package from [unsupported] _without prior notice_. We
have since been reminding each other, but it looks like the word
hasn't reached some of us.

Perhaps it is time to put this in the guidelines? We cannot just
assume that everyone would be in the know, although I expect that the
individuals we (s)elect to take care of the AUR have at least this
much understanding. But I don't think that's the main issue here,
which brings me to:

 My proposition is: could it be a policy to check with the maintainer
 first before initiating a move? If someone wants to keep a package
 then they should be able to, especially since they could not have been
 doing such a a bad job if their package has become popular.

Now, this is something I find very strange. I wish I had the previous
discussions to link to, so you could better understand what I am about
to mention.

You have to understand that the AUR started out with a purpose, a
purpose which has not, and will not for the foreseeable future,
change. It serves as a platform for proposing packages for
redistribution, and not a platform for competition. Imagine:

* Jane needs package foobar
* Jane cannot find package foobar in the repositories
* Jane creates package foobar for her own use
* Jane now wants to share package foobar so this cycle does not repeat

When you upload a PKGBUILD, you are _sharing_ that PKGBUILD. If a
Trusted User wants to adopt it, that's a good thing for the community.
You don't have to feel challenged, because we are all users, one and
the same, TU or not. You can continue providing assistance if you see
the need, by communicating with the TU.

When I myself started out contributing PKGBUILDs to [unsupported], I
did it hoping one day they will receive enough votes and be adopted by
a TU, enabling the packages to be redistributed to the masses in
binary form, easily accessible with the package manager. I believe
this is the true spirit, the Arch Spirit.

Of course, it is not wrong to want to keep maintaining a package
yourself. It just does not make sense to me. If you really have a
problem, report the packages affected and we can drop them for you.

Re: [aur-general] Moving packages to Community

[Ray Rashif]

On 6 February 2011 03:35, Ionuț Bîru ib...@archlinux.org wrote:
 I moved a lot of packages from AUR in community/extra and every time i did
 sent a thank you note. From that amount of messages i sent, only once i
 got a reply. ONCE.

 Should i be dissapointed? I guess yes. I am? No.

No need. The first comment from you about moving already counts as closure.

What I do is allow for a grace period before (1) uploading the package
to repo and (2) deleting the package from AUR. I notify (via comments)
at least a day before uploading, and delete the package a day after
uploading. So that's a three-day process.

Now, I just remembered a good example where we appear to have not
bothered with adopting a package into the repositories: q7z [1]

But really, the AUR maintainer can keep working on the PKGBUILD even
if someone brings it in. The difference is you don't submit the
PKGBUILD - you send an e-mail with it attached.

And while we like to joke about making Arch greater and/or kicking
butts, there isn't really anything of that sort. We just help each
other out to fulfill our needs, and the distribution grows along with
us. Humbly.

[1] http://aur.archlinux.org/packages.php?ID=12822

Re: [aur-general] Moving packages to Community

[Ray Rashif]

On 6 February 2011 06:01, Thomas S Hatch thatc...@gmail.com wrote:
 I don't think that Hilton was trolling you Maxime, just poking a little fun
 at Jelle.

He was so engrossed with moving a package (think about the excitement
he must have had) that he forgot about the formalities involved.

Re: [aur-general] Add pyopencl to [community]

[Ray Rashif]

On 4 February 2011 04:21, Andrea Scarpino and...@archlinux.org wrote:
 On Thursday 03 February 2011 13:49:26 Stéphane Gaudreault wrote:
 * Add pyopencl to [community] (I will use a better name, something like
 python2-pyopencl)
 python2-opencl sounds better IMHO.

It's all good but one thing: there either needs to be a provision for
pyopencl or inclusion of the upstream module name in the description,
so that the package naming doesn't hamper searches and common
knowledge (i.e people would know 'pyopencl' only). I see the same
issue with pyqt. Didn't we already have some discussion about the
module naming convention during the major python transition?

Re: [aur-general] [community], [unsupported] and AUR

[Ray Rashif]

On 3 February 2011 11:14, Xyne x...@archlinux.ca wrote:
 Hi,

 A post on the forum[1] brought my attention to the Official Repositories wiki
 page[2].

 A recent note by Louipc states: Technically, both the [community] and
 [unsupported] repos make up the AUR..

 Is this really still true? The AUR website is completely independent of
 [community] now and I believe that all technical ties between [community] and
 [unsupported] have been severed.

 AUR pages on the wiki clearly refer to [unsupported] in many contexts, e.g. 
 the
 main AUR article[3] contains the following snippets:

 The Arch User Repository (AUR) is a community-driven repository for Arch
 users. It contains package descriptions (PKGBUILDs) that allow you to compile 
 a
 package from source with makepkg and then install it via pacman.

 [community], unlike AUR, contains binary packages

 I also believe that most users immediately think of [unsupported] and only
 [unsupported] when speaking of the AUR.

 Furthermore, both are repositories in their own right, so it is a misnomer to
 refer to them as a singular Arch User Repository.


 What is the point of claiming that [community] is part of AUR? It seems like 
 an
 unnecessarily confusing vestige of [community]'s origins.

Clearly, the move to devtools has decoupled the binary repository from
the AUR web, but I don't think it has decoupled the repository from
its purpose.

Re: [aur-general] poppler 0.16 rebuild

[Ray Rashif]

On 31 January 2011 23:30, Jelle van der Waa je...@vdwaa.nl wrote:
 On Mon, 2011-01-31 at 15:50 +0200, Ionuț Bîru wrote:
 Hi,

 the rebuilding is almost over and was already moved from staging to
 testing in the morning, the only package that doesn't build is
 openscenegraph and is not related to poppler api breakage.

 Sergej can you look at it and try to fix it?


 Openscenegraph  has some funny ffmeg errors, http://dpaste.org/wOAB/
 I'll check it tonight if i find some time

OK it's not what I thought it was:

bugs.gentoo.org/show_bug.cgi?id=347481

A chat on #openscenegraph reveals an ffmpeg build with
-D__STDC_CONSTANT_MACROS from december 2010 worked.

You have to disable ffmpeg for now if anyone wants this rebuilt. And
it's not like it's that affected by poppler. Just remove it from the
TODO.

Re: [aur-general] Temporary Inactivity

[Ray Rashif]

On 29 January 2011 06:36, Jonathan Conder jonno.conder+a...@gmail.com wrote:
 Hi everyone,

 I'm off to the beach again and won't be back until Monday. This time there
 is something on my todo list, which is to move the mythplugins-* packages
 from community-testing into community once libmysqlclient is updated. If
 this happens while I'm away it would be great if someone could do that for
 me. If not, it doesn't matter that much because the only package it will
 break is mythplugins-mythzoneminder, which I doubt is used by many people.

OK, we'll keep tabs on that.

Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all

[Ray Rashif]

On 19 January 2011 22:23, Stéphane Gaudreault steph...@archlinux.org wrote:
 As the maintainer of A, it is not your job to track dependencies of B and D.

 Again, look at the problem from a different point of view. If tomorrow
 dependencies of B change to

 B - C F (direct dependecies)

 does it mean that A (and **all** other pkgs that depends on B) should be
 updated to include a dependecy on F ? What if dependency on E is removed from
 C PKGBUILD ? Maintaining a package with such rules will be a nightmare.

If A depends on B AND C while B depends on C, then it is correct to
list both B and C as dependencies of A. That is as proper as it gets,
and this most of us do not practise currently. Aside from any
technical disadvantage, it is just clutter to my eyes.

It is also correct to list only B as a dependency of A, since B would
pull in C, but this correctness is only assumed correctness, provided
link-level dependency has not been checked. This, most of us do
currently. PKGBUILDs and pacman dependency lists are easy to look at.

I don't see a need to 'settle' this one. You may not list glibc
because it simply makes no sense to not have it at the time of
installation. It can be as far deep down as F, but ultimately it is
the packagers' (and community's) responsibility to incorporate
dependency changes. As a community, changes like this are hard to
miss. C getting out of B's dependency chain does not happen a lot.
When it does, someone can report it. So we (should) stick to the
simple(r) way - the current way.

Re: [aur-general] Time to Step Down

[Ray Rashif]

On 8 January 2011 08:28, Aaron Bull Schaefer aa...@elasticdog.com wrote:
 Fellow Trusted Users,

 After almost 4 years of being a TU, I've had less and less time to
 dedicate toward maintaining my packages, and so I think it's finally
 time for me to step down. Arch users definitely deserve a better
 response time than what I've been able to provide lately, and
 unfortunately, my priorities have shifted elsewhere.

It happens - you're not alone :) Anyway, best of luck to you in whatever you do!

Re: [aur-general] Audio plug-ins name convention

[Ray Rashif]

On 4 January 2011 21:54, Bernardo Barros bernardobarr...@gmail.com wrote:
 Hi all!

 I'm packaging some audio plug-ins and I wanted to know if there is any
 naming convention to this, as with fonts.

Nope.

 Since there are different formats (LADSPA, LV2,  DSSI and VST), if we
 follow the convention used with fonts (like ttf-x), we will get:

  lv2-x
  dssi-x
  ladspa-x
  vst-x

 It makes sense?

It makes sense, no doubt about that. Remember to also provide the
general name of the plugin. An example:

'lv2awesome' is a set of LV2 plug-ins. To fit in with the naming
convention, you can name it lv2-awesome, but have:

provides=('lv2awesome')

If that doesn't conflict with anything. Strip 'plugins' and the type
from the name (for the package, not the provision) and try to be as
short as possible, but still make sure people know what it is from one
glance. A real example:

inavada-studio-plugins - ladspa-invada
  provides: 'invada-studio-plugins'
  groups: 'ladspa-plugins'
  desc: A set of LADSPA audio effect plug-ins ported from VST by
Invada Records

invada-studio-plugins-lv2 - lv2-invada
  provides: 'invada-studio-plugins-lv2'
  groups: 'lv2-plugins'
  desc: A set of LV2 audio effect plug-ins ported from VST by Invada Records

For stuff that are apps by their own rights, like calf, skip the
convention. Strictly use the (proposed) convention for plugins-only
packages.

For VST, use the following:

linuxvst-*
win32vst-*

To be honest, conventions only appear when in use in the
repositories. We don't yet have that many plugins in extra/community
to warrant use of a convention.

Re: [aur-general] tenshi

[Ray Rashif]

On 2 January 2011 04:15, Xyne x...@archlinux.ca wrote:
 Florian Pritz wrote:

 I noticed tenshi [1] hasn't been updated for quite a while and I'd like
 to maintain it (and perl-io-bufferedselect which is a dependency in
 newer versions and not yet in AUR/repos) in community if 1) the current
 maintainer is okay with that and 2) three TUs agree because it sadly
 doesn't satisfy the 10 votes or 1% usage rule.

 I've got a working PKGBUILD for 0.12 and I'm already using it on my
 systems. In case I can't move it to community I'll publish that later.

 CC'ing the current maintainer (Ryan).

 [1] https://aur.archlinux.org/packages.php?ID=14088

 --
 Florian Pritz -- {flo,bluewi...@server-speed.net


 There are two unrelated issues here. The first is that you want to actively
 maintain a package that you use and which appears to be neglected by its
 current maintainer. If the maintainer does not update the package in response
 to your email or says that you can take it, then it's obviously fine for you 
 to
 take it. The maintainer may respond by updating it though, as he's been active
 as recently as October.

 The second issue is one of moving this to [community]. The package has been in
 the AUR for 3 years yet only has 6 votes. I doubt that it takes long to
 compile either, so why do you want to move it to [community]? I see no benefit
 in doing, and it will only complicate maintenance for you. I think you should
 just maintain it in the AUR, at least until it reaches the vote threshold.

+1 leave it in the AUR.

Re: [aur-general] [arch-dev-public] Breaking the unspoken rule: AUR helper in [community]

[Ray Rashif]

On 30 December 2010 20:45, Xyne x...@archlinux.ca wrote:
 Ionuț Bîru wrote:

 Maybe we should change that and include all aur helpers that interface
 with the official json api from aur.archlinux.org.

 I would only restrict applications that download from (and maybe upload to) 
 the
 AUR. There may be acceptable uses of the API beyond that, such as a generic
 search application that checks repos and the AUR, e.g.

 $ findpkg foo
 foo is in the AUR: url

 That would still make the package origin clear and require the user to
 understand how the AUR and ABS work, and it does not present any security
 risks.

Searching, downloading, or uploading - all communicate with the AUR
and provide the user with an alternative interface. This integrates
the AUR into the distribution, to some extent.

* john installs archlinux
* john installs aursearch
* john searches aur
* john realises there is no download or build helper he can install
* john complains and demands for a helper in the repos, citing the
search helper as useless

However, a search tool is pretty trivial and I don't see any other
problems aside from complaints like the above. IMHO a search tool can
be kept in our repos. However, a download tool asks for more trouble.
For instance:

Hi..I have a problem with barsoft. Downloaded and installed in archlinux
What? Didn't we say NOT to redistribute our software? archlinux is
now in the hall of shame.

We currently have the defense that the AUR is _completely_ decoupled.
This has allowed us to have all sorts of things in there. The only
action one can take on a PKGBUILD is to access the AUR, personally or
by means of third-party, unsupported utilities.

As for an upload tool, I don't see any immediate issue. It's got
nothing to do with anything but putting up files. But one case where
it might pose a problem is if someone decided we're bad for letting
users upload their restricted non-redistributable software. We would
also not have the completely-decoupled defense in the event of a
dispute.

Re: [aur-general] VirtualBox in [community]

[Ray Rashif]

On 29 December 2010 00:24, Heiko Baums li...@baums-on-web.de wrote:
 Am Tue, 28 Dec 2010 22:49:32 +0800
 schrieb Ray Rashif sc...@archlinux.org:

 virtualbox-guest-additions - virtualbox-additions-linux ('guest' not
 important; shall be implied by description)
   desc: Additions for Linux guests (userspace tools)

 virtualbox-guest-modules - virtualbox-modules-linux (as above)
   desc: Additions for Linux guests (kernel modules)

 ...

 No. The additions CD image can be bloat to some people only running
 vbox with an (arch)linux guest.

 But wouldn't this be a bit better?

 virtualbox-guest-additions - virtualbox-additions-archlinux ('guest'
 not important; shall be implied by description)
  desc: Additions for Arch Linux guests (userspace tools)

 virtualbox-guest-modules - virtualbox-modules-archlinux (as above)
  desc: Additions for Arch Linux guests (kernel modules)

They're actually distro-independent. We just build, (re)package and
move stuff around to the proper directories fit for whatever distro we
use. Anyway, it's not wrong - either linux or archlinux serves the
purpose here.

Re: [aur-general] Remove ardour3-svn

[Ray Rashif]

On 21 December 2010 06:30, Xyne x...@archlinux.ca wrote:
 I don't agree with him. Any real archer will want to use a PKGBUILD to do 
 this.
 Removing it from the AUR will just force people to recreate the same PKGBUILD
 themselves and for no good reason. Admittedly the AUR in combination with the
 various AUR helpers makes it easy for a casual user to install the package, 
 but
 I don't think there will be a wave of disinterested users installing the
 package. Plus those very same AUR helpers make it trivial to quickly update to
 the latest version with a single command.

 I recommend leaving it on the AUR while making it *very* clear that it is
 strictly for development and testing, and that users should subscribe to the
 upstream mailing list.

 You could do this by including very visible instructions in the post_install
 message (along with a once-off post_update message to inform existing users).

 This is only my opinion though. I'm interested in the other TUs' views.

I used to warn and advise against uploading any kind of buildscript
for ardour3. I believe I was wrong. I believe the biggest headache a
PKGBUILD solves is dependencies. So +1 this stays with post-install
messages.

Re: [aur-general] Moving calibre and unetbootin to [community]

[Ray Rashif]

On 13 December 2010 20:24, Jakob Gruber jakob.gru...@gmail.com wrote:
 On 12/13/2010 01:00 PM, Giovanni Scafora wrote:

 Hi guys,

 I'd like to move calibre [1] and unetbootin [2] to [community] repo.
 As you see, respectively they have 435 and 1401 votes.
 What do you think about?
 Opinions?


 [1] http://aur.archlinux.org/packages.php?ID=20406
 [2] http://aur.archlinux.org/packages.php?ID=21989



 These were both mentioned in the Arch holiday madness! nominations thread.
 Maybe it'd be better to wait until the nomination deadline (Dec 24th)
 expires to avoid spoiling the christmas surprise? ;)
 I don't feel too strongly either way though.

Well, it's not a surprise anymore for these two :(

So I say, bring 'em in :)

If we really want to wait out for that thing, then I say we officially
declare a TU hiatus. Otherwise, it has no effect and we can carry on
adopting as and when we like.

Re: [aur-general] TU Bylaws Amendment (SVP Section): Discussion Period

[Ray Rashif]

On 12 December 2010 11:39, Loui Chang louipc@gmail.com wrote:
 On Sun 12 Dec 2010 04:21 +0100, Xyne wrote:
 The following is a proposed replacement for the current SVP section of the TU
 bylaws:

 https://wiki.archlinux.org/index.php?title=Bylaw_Amendmentoldid=124557

 The changes address several issues recently brought up on this list. Briefly,
 these include:
 * enabling a vote to pass in the absence of quorum when more than 50% of 
 active
   TUs have voted YES
 * enabling a vote to fail in the absence of quorum when 50% or more of active
   TUs have voted NO
 * clarifying the text to eliminate ambiguities

 Please see Kaiting's [aur-general]Amendment thread and Loui's
 [aur-general][PATCH]tu-bylaws: Amend Standard Voting Procedure thread for
 more details.

 This message marks the beginning of the 5-day discussion period before the
 amendment is put to a vote.

 Can we get that as a patch so I may apply it to the hosted version if
 the vote passes? The content should probably be on the mailing list as
 well.

We can compare-and-contrast better looking at a patch, so +1 to that.

Re: [aur-general] Arch holiday madness! nominations

[Ray Rashif]

On 13 December 2010 02:19, Stefan Husmann stefan-husm...@t-online.de wrote:
 Am 12.12.2010 18:51, schrieb Thomas Dziedzic:
 On Sun, Dec 12, 2010 at 9:58 AM, Brad Fanella bradfane...@archlinux.us 
 wrote:
 On Sat, Dec 11, 2010 at 11:02 AM, Thomas Dziedzic gos...@gmail.com wrote:
    * It’s that time again, to give and receive presents, and to push
 the boundaries of what defines procrastination. That is why some of
 the trusted users (td123  kaitocracy) are willing to listen to the
 community for package nominations to the [community] repo.

 Interesting concept!

 By some of the trusted users (td123  kaitocracy), are you implying
 that this is a project with sole participation from those two? Because
 I have been relatively lazy lately, and helping out with packaging
 seems fun (in my twisted, geeky, probably borderline-psychopathic
 mind). So if you ever need a monkey slave to make you a ham and cheese
 sandwich (or build and maintain Christmas packages for that matter), I
 think you'll know who to turn to.

 Just kidding about the mental disorders by the way...

 Regards,
 Brad


 No, it's not just limited to those packages. I only mentioned kaiting
 and me because I asked in #archlinux-tu and no one except kaiting
 agreed to do it. It is open to anyone, so far, you and schuay are now
 participating.


 If you like I can take part too.

I'm gonna sit down and watch, while taking down a list of candidates.
By the end of this, any one or more of the candidates that have not
been picked up, I will handle :)

Re: [aur-general] voting period for Dave Reisner

[Ray Rashif]

On 12 December 2010 04:05, Ionuț Bîru ib...@archlinux.org wrote:
 good news. This is the first time, since i'm a TU, when we reached 100%
 quorum.

First time in the history of the AUR as we know it. Congrats and welcome!